1. Proper use of <h#> tags
Many themes I’ve looked at do not use <h1>, <h2> and so forth properly.  Remember that the search engines (and POSH) dictate that the header tags place emphasis on specific information (which should include things like the title, the date of publication or the author).  Comb through the single post and main index templates to make sure there is consistent use of both <h1> and <h2> tags (at the very least, and preferably <h3> as well) and adjust the CSS to get the look and feel you want instead of relying on class-based <div> markup.

2. Too many links on the index page
Two problems here - first, the increase in links (past 40) decreases or dilutes the value of importance placed on the page.  At the very least, push the most important posts on the front page and consider whether or not you need the others.  Second, why are you sending people elsewhere in the first place?  Sure your friends might run a great blog but do you really need 100 listings in your blogroll?  Consider that external links in your posts should not go past 2 each and that you should keep the total number of links as close to 40 as possible.

3. Bad keyword choices
Especially on the main index page, it is critical that you consider your choice of keywords and mold your page to the proper density.  Use a free tool like Google’s Keyword Tool to find ones if you’re unfamiliar with structuring keywords.

4. Alt and title text
Always, always, always include alt attribute text on images and preferably include a title attribute on links and lists so that search engines know what tags to associate with the image.

5. Unique keywords
Every page in the site should have a) unique titles and b) different keywords.  You may even opt to remove the name of your blog from the page title because in the end it’s just a vanity thing isn’t it?  There are several plugins that can help you do this by converting the text and tags on the posts into the keywords and description <meta> elements.

6. Fix your markup
Bad markup is, well, just bad.  This goes for both the HTML as well as the RSS feeds.  By default (the newer versions of) WordPress provides at least 4 places to get the feeds from: www.domain.com/feed/, www.domain.com/comments/feed/, www.domain.com/wp-rss.php, and www.domain.com/wp-rss2.php and you should provide appropriate links to them as needed.

Now many of you (all 5 reading this post) are probably asking why I don’t even follow these rules necessarily and the fact of the matter is that for this blog, I don’t personally care.  I publish this for information purposes and largely for my students, not really for the public at large.  Should I teach by example, sure I should; but there are many other ways to get this information across, so I do as I wish.

First, I’ve been neck deep into two threads of development.  On the one side, my department is (finally) being split (appropriately) into two working groups - R&D and Implementation.  The R&D team will (hopefully) continue it’s digging into the depths of Silverlight, coming up with better and better ways to reap the benefits of the environment and delivery mechanisms.  The Implementation team will be finishing up installation of the Digital Asset Management system amongst other tasks.  On the other side, because of our core focus on Silverlight, I’ve had to undertake a crash course in Flash CS3 using AS3 for a number of projects and have to say, I like it.  Above everything else, not attaching scripts directly to objects and the flow of the class structure is much better (I know, I know, it was pretty much all there in AS2 but this just all seems more congruent).

NBC’s 2008 Olympics web site and notably the video delivery was, in my opinion, very well done considering the enormous task at hand.  For Schematic (the web and application designers) I actually have very few complaints - the UI was well thought out and to all the naysayers out there, try architecting a site of that magnitude - it’s so easy to put something down until you’ve been on the other side of the coin.  IMHO - the Silverlight experience was about as good as it gets at the moment and for those who keep complaining that Flash is better than Silverlight, maybe it is, but given a 10 year head start, I personally think Flash should be farther ahead than it is.  My only complaint is that the site was doggedly slow.  However, special kudos to Limelight for the rather phenomenal feat in delivering the quantity of content without dying out (for an extremely good introspective, check out this Jason Perlow article "Limelight Networks: Why the Olympics didn’t ‘Melt’ the Internet").

So in the meantime, I’ve completely lost my bearings on any of the social networking mire and it tells me one thing … did I really need it to survive anyway?  I know there is a lot of substance behind the theories in social networking but for the most part, everything I am seeing now is just fluff and marketing - everyone jumping on the bandwagon and trying to leverage UGC to advertise and little else.  However, underneath it all, we are beginning to see the seedlings of the so called Web 3.0 - tagging is starting to become a driving force more than it has in the past, and starting to reach a point where critical mass might actually be possible.

Along those lines, I recommend reading David Weinberger’s "Everything is Miscellaneous" which deals with the topic of how tagging can remove the need for organization and yet still make things more efficient.  Visionary, though still a way off, I truly think we will see the emergence of smart agents that will handle tasks for us.

Also been finishing Zittrain’s "Future of the Internet" which somehow got terribly boring towards the end, Sipser’s "Theory of Computation" (for school) and "Art of Agile Development" (O’Reilly).  Maybe I need to lay off the books a bit.

School (as in me finally going back to school to finish my graduate work) starts next week and I am extremely excited and anxious.  I believe there are only 8 in the program and after my experiences at Cornell (you know, the Psych class with 2,000 students, etc) it should be refreshing and interesting.  Not sure how I’m going to juggle iStream, teaching, MadeByGirl and school but I’ll take it one day at a time.  Speaking of MadeByGirl - we just made a big big sale to Selfridge’s in London, so if you happen to be shopping there anytime, we’d love to see a photo of them in the store.

Hopefully, finances willing, I am going to plunk some coin and pick up the item on my most wanted (and needed) list - the Dell E4200.  Purportedly being released within the next couple of weeks, it’s a 2.2 pound, 12" subnote with a solid state drive, magnesium case, and a 19 hour battery life.  Don’t get me wrong, I love my trusted Latitude D600 (and even Jennifer’s MacBook Pro) but I think I need some new juice under my fingertips (and not to the extent of my workstation at iStreamPlanet).  On the extended wish list is the HTC Touch Pro though at the moment the details and pricing still seem a bit sketchy despite the unconfirmed Sept 2 release date.

Note for my students: especially #s 1, 2 and 6 I’ve spoken about in class frequently - if you have questions about any of this over the coming week - ASK!

But there are some principles to consider during and after you write your CSS to help keep it tight and optimized. Optimization isn’t just minimizing file size — it’s also about being organized, clutter-free, and efficient. You’ll find that the more knowledge you have about optimal CSS practices, smaller file size will inevitably come as an direct result of their implementation. You may already be familiar with some of the principles mentioned below, but they are worth a review. Being familiar with this concepts will help you write optimized CSS code and make you a better all-around web designer.

1. Use Shorthand
Using shorthand properties is the single easiest practice you can do to cut down your code (and coding time). There’s no better time than the present to start this efficient coding practice, or to review it. Margin, border, padding, background, font, list-style, and even outline are all properties that allow shorthand (and that’s not even an extensive list!).

2. Axe the Hacks
But now we know that using conditional comments to serve hacks correctional declarations for IE6 and IE7 is an accepted practice, even recommended by the Microsoft IE development team. Using conditional comments to serve IE-specific CSS rules has the added benefit of serving a cleaner, and therefore smaller, default CSS file to more standards-compliant browsers, while only those browsers that need the hackery daiquri (i.e. IE) will download the additional page weight.

3. Use Whitespace Wisely
Whitespace, including spaces, tabs, and extra line breaks, is important for readability for CSS code. However, whitespace does add, however miniscule it may be, to page weight. Every space, line-break, and tab you can eliminate is like having one less character.

4. Prune Frameworks and Resets
If you’ve chosen to use a CSS framework (including ones you’ve written yourself), take the time to review the documentation as well as every line of the CSS file. You may find that the framework includes some rules that you don’t care to use for your current project, and they can be weeded out. This goes for resets as well.

5. Future-proof your CSS
However, I’m warming up to the idea of separating layout styles from the rest of the styles, and giving layout it’s own file, or at least it’s own section.

6. Document Your Work
Documentation, including markup guides and style sheet guides, is not just for group efforts — they are just as important for a one-man design team. After all, a year after working on other things, revisiting one of your own projects can feel quite foreign. Your future self might appreciate reminder of how your CSS grid framework is supposed to work, or what pages already have a treatment for a secondary action form button, and it will save you or someone else from appending redundant and unnecessary rules to your CSS.

7. Make Use of Compression
Some great applications have been created to compress and optimize CSS for you, allowing you to serve a human-unreadable but still browser-friendly files that are a fraction of the origional working copies.

[Read the article in its entirety at Smashing Magazine]

Twitter isn’t for everyone, and you may have dismissed the service a long time ago. But regardless of your own use, it’s hard to dismiss the phenomenon itself and the passion of so many that has built up around it.

No matter how long the outage du jour, Twitter users continue to stay attached to the service despite an ever-changing backdrop of alternatives.

Blogging isn’t for everyone either. But unlike blogging, Twitter enjoys a far a greater variety of users — they include people, many people, who would never think of starting a blog and people who would never touch an RSS reader. The 140 character limit is a plus for Twitter, but it isn’t all.

What explains the Twitter phenomenon then? What produces the positive feeling and the strong attachment among those who tweet? And moreover: How can other systems learn from this?

The answer lies in understanding Audience.
Twitter has a simple premise: You tweet & the message is pushed to your friends. The actual mechanics are slightly different (messages go to everyone who follows you, whether they’re your “friends” or not, assuming your stream is public) — but from a user’s perspective, the circle of receivers consists only of the people they know. Everyone else is part of a faceless crowd that’s hidden behind the follower count.

This simple premise holds the key to Twitter’s success: messages go to a well-defined audience. In the moment you release a tweet, you know who’s on the line and you have an idea of who can catch a glimpse of your message. @replies are the best illustration for this sense of audience: Even though Twitter is not a point-to-point message delivery system (let alone a reliable one), @replies are sent with the understanding that they will be read by the intended people because they are known to be in the audience. (Imagine a newspaper article that suddenly greeted a specific reader.)

Blogging on the other hand has no such clearly defined audience. An aspiring blogger who hasn’t crossed the chasm speaks into the void. Direct feedback can only come in the form of written comments (a relatively high barrier of effort) and it’s diminished by spam and vocal trolls these days.

FeedBurner’s subscriber count only provides the equivalent of Twitter’s opaque follower count and MyBlogLog didn’t solve this problem either.

So it’s not surprising that the majority of blogs are abandoned — the most-cited reason being “No one was reading it.” No one might be following your Twitter stream either, but Twitter is designed for network effects to take hold and given the natural reciprocity among groups of friends, it’s likely that most people have at least a handful of followers they know.

Back to Twitter: Why Audience works
Twitter works and enjoys such strong attachment because it provides real-time access to a well-defined audience. The backlog of all previous tweets is a guarantee of permanence (you can even search it) and you can catch up on it anytime. As a result, people use Twitter because they have an idea of who will see their lightweight messages and this sense of audience is reinforced by @replies, re-tweets and references in future conversations (online and offline).

Designing for the sense of Audience is a powerful tool to create cohesion and a sense of utility among users of a service. This lesson from Twitter can apply to many other services too. But before leaving the current discussion, it’s helpful to look at a service that has missed the full power of Audience so far.

Facebook: Designed for Audience? Not so much.
Facebook isn’t about Audience? That’s ridiculous, you’ll say — so let me clarify. I fully agree that social network profiles are all about self-expression and being seen, but a platform for self-expression isn’t necessarily designed for the audience that does “the seeing.”

Profile Pages on Facebook can have audiences of course, but this requires that users continually roam Facebook to look for news in their network. Facebook realized this limitation and introduced the News Feed. Its intent was to move a user’s “acts and performances” from the stage of the profile page to a single and central stage, a single place for Audience.

Sharing with the News Feed: Did it ever reach my friends?
Facebook was the first major social network to introduce the News Feed concept, which has since become a standard sauce for stickiness in many places (although not StudiVZ surprisingly). But Facebook’s implementation of the News Feed doesn’t capture the full power of designing for Audience: While Twitter distributes every message consistently, Facebook decides algorithmically which update is shown to whom. Algorithmic filtering is nice in theory, but such black-box behavior is simply unpredictable for the user.

“When I post new things, will my friends actually see them?”, one might wonder. And conversely: “Have my friends posted something that I’m not seeing? The news feed is cluttered right now with people I don’t care about.” Anything that’s unpredictable produces a feeling of uncertainty — and that’s never a comfortable feeling.

Even with Facebook’s recent attempts to introduce smarter filters, users only have relative means to customize their feed (more of this, less of that). Furthermore, there is mostly just one kind of feedback that users can give on the News Feed: comments. Imagine a concert, in which you could only leave written notes as you left — no clapping, no booing.

Because users don’t really know who’s listening on Facebook and who isn’t, the platform hasn’t been embraced as a place to publish proactively. Publishing events or photos is mostly push-driven (and generates an email — “you are invited to an event” or “tagged in a photo”). But for everything else you share, do you know if it ever reached your friends?

Who capitalized on this gap? FriendFeed.
It’s the same setup as Twitter, but with more content: You know who’s listening and you choose the people you listen to. A useful premise but it also has a catch: the word “more”. Too much content, too many people — which is exactly the problem that Facebook is trying to address with its algorithmic feed. But what’s a solution then? It’s not the “middle ground” and it has nothing to do with smarter filters.

The answer is feedback loops. But that opens up another discussion. If you’d like to read more, I have a separate post on my website, in which I elaborate on how to design for Audience.

Gregor Hochmuth is the founder of zoo-m.com Interactive, where he created Mento, LaterLoop and other services. He currently lives in Berlin, Germany, where he worked as an analyst for Hasso Plattner Ventures and has written about German startups on TechCrunch.

These are the elements of functional design, the process of responding to the needs or desires of the people who will use an item in a way that allows their needs or desires to be met. Functional design is both an outcome and a process. As an outcome, it describes products that work well to perform their assigned tasks; as a process, functional design is a set of practices guided by the principles that produce that positive outcome.

I’m not going to bother repeating the article here - please take the time to jump over to SM and read it.  However, here’s a quick synopsis:

1. Consider the product’s goal
Determine that one primary goal of the site and make sure that everything you do revolves around that fundamental concept.  Every addition you make, every tool you provide, every piece of text you write should be dedicated to that goal.

2. Consider who will be using it
As JJG proposes, identifying the target audience can be a critical factor simply because most designers either fail to take it into consideration or misjudge it.  Audiences vary and so do their wants, needs, and abilities.  Cater to that need: a product has to work equally for all its potential users if it’s to accomplish its goal.

3. Consider what your audience intends to do with it
What your audience does may not be what you do.  YOU are not the audience, your users are.  Every user comes with intention, learn what those intentions might be.

4. Is it clear how to use it?
We designer/developers have a tendency to go beserk with our functionality.  Don’t.  "Clarity is the key to functional design".

5. How does your user know it’s working?
Provide feedback…it’s the only way your user knows that he or she is using it right.  Provide visual cues, highlight the necessary parts.

6. Is it engaging to your users?
One of JJGs two tenets and the one that I believe is fundamental to all things Web - is it engaging.  I harp on it nearly every quarter but I don’t think many people really see it.  Example: four times this week alone I’ve seen references to Blackberry’s as engaging - owners cannot seem to put them down or stop fiddling with them.  Whether its the feel, the interface, the haptics or the information it provides, there is definitively something engaging about them.

7. How does it handle mistakes?
JJG makes a big point of discussing error handling.  We as dev-igners pretty much think we never make mistakes.  Just because you can run through your web site and never encounter an error doesn’t mean your user won’t.  Users make mistakes.  Or more succinctly, your user will not do the same things you do.  How does the site correct, adjust or respond to errors?

I find myself in a place I often do, at the interactive design phase of a project - that giddy phase after all the due diligence has been done and we’re looking for that next great app.  The coders are itching to get started, the client is anxious for the alpha builds.  And here I sit trying to convey all the information and ideas I’ve aggregated into a unified yet flexible interface.  And just like last time, it once again is for a client bigger than I find comfortable, and feeling as though there is no real answer.

So some basics…it’s an internet application - a “rich” internet application - designed to deliver a massive video library of both live and on-demand content.  It should also be viral and embeddable.  It has to be lightweight, but it also has to deliver as much engaging interaction while maintaining its efficiency in delivering video (and of course advertising).

So what is it that would make this application truly rich?

I had an interesting discussion with my significant other last week after explaining the dilemma of the project.  She and I have very divergent opinions about internet applications.  Ever the tech-nerd and business strategist, I always look for the efficiency, for what will monetize, for what will create the best business scenario.  For her, a designer, it’s the utility, the engaging atmosphere that takes precedence over eveyrthing else.  I’m Windows, she’s Mac (literally…in our household it’s Dell versus Apple).  I’m Windows Mobile, she’s iPhone.  I’m text, she’s typography, i’m bits, she’s color.

In any case, she explained to me that the reason that she preferred the iPhone over her last “piece of junk” (a Windows Mobile phone) had little to do with that the applications themselves did anything different, it was that the interaction with the phone simply made it more engaging and thus made it more apt to (continue to) use it.  And that was they key, she said, “make it engaging and they will stay.”

Now, my partner already knows a thing or two about traffic and the importance of keeping eyeballs on the content.  She runs her own online store that within 3 months became profitable and runs a blog that pulls in exponentially more traffic than this soapbox.  More than that she understands how to keep her customers interested, happy and loyal.  She demonstrates for me the simplicity of the iPhone app design - not of the unit as a whole, but of the generally consistent visual nomikers and motions shared by all the apps.  She points out the vast difference in providing search boxes that actually instruct, detailed breadcrumb trails that actually do something, and the fact that the system as a whole delivered information efficiently but in a fun way.

Any of the 100+ students that have mucked their way through my UCD classes will attest that I harp on two major things in UX design - being efficient and engaging (not principles I came up with myself - thank Jesse James Garrett for that definition).  So what happened that I so easily forgot these principles in trying to lay out this design.

Her comments and demonstration got me thinking.  And thinking.  Which led to some quick drafts, a few poorly drawn sketches, some minor storyboards.  And now I here I am trying to synergize that last little piece of science that will turn my Frankenstein from idea to life.  Through the morass of mapping mashups, social network hooks, video controls, playlists, advertising, viral components and colors, somewhere lies the answer.  Will this one be it?  Will this design be the rage or will it flop?  Hard to tell at this point but I think the ideas are good ones. Coaxing them into coalescing into something bigger than the individual parts is the goal.  Let’s see if this truly ends up rich.

Stage 8H is best known as the place where Saturday Night Live is filmed. This week, though, it’s been turned into an ad-hoc data center as part of NBC’s efforts to stream thousands of hours of live Olympic coverage over the Internet.

Instead of the usual crop of comedians, NBC will have dozens of people watching every hour of the games, looking for highlights that it can chop up and make available on-demand. It’s just one piece of an elaborate arrangement that shuttles the events in Beijing back to the U.S.

From each of the dozens of Olympic venues, a high-definition video feed is delivered over fiber-optic cables to the International Broadcast Center that has been set up in Beijing. A bunch of encoders and Windows Media servers get the video into an Internet-ready format. From there, it travels via satellite to NBC’s headquarters in New York.

There, NBC actually adds a one-minute delay, allowing its cadre of live bloggers in Stamford, Conn., and elsewhere to write their text and have the video and commentary synchronized. Once ready, it goes from NBC to Limelight Networks, a content delivery network, which has 1,000 servers just for the live events sending the content to various Internet service providers, who then shuttle the content directly to their customers. (See chart below)

(Credit: Susan Dove/CNET News)

Making it play
Limelight Chief Strategy Officer Mike Gordon said his company is prepared for this to be the biggest live event the Internet has ever seen. “I would not be surprised at all to get 1 million viewers,” he said. “We’re certainly prepared for whatever the audience turns out to be.”

Mike Gordon, chief strategy officer, Limelight Networks

(Credit: Limelight Networks)

That said, there is clearly an element of risk in all this, considering NBC’s history of live Olympic streaming has been limited to broadcasting a single game, the gold medal ice hockey match in Torino, Italy, two years ago.

“NBC has always taken risks and is always trying to do more than it has in the past,” said Perkins Miller, the NBC senior vice president in charge of the Internet push. “It does keep me up at night when I think about streaming 2,200 hours (of live coverage).”

The massive effort has come together in a remarkably short amount of time. Microsoft’s deal to power NBCOlympics.com dates back only to January.

NBC had a pretty good idea what they wanted to do and had built some mock-ups of the player prior to deciding to partner with Microsoft.

Initially, they expected to use Adobe’s Flash, given that is the standard for video delivered over the Internet these days. But, as they began to hash things out with Microsoft during a series of all-day meetings at NBC’s 30 Rockefeller Plaza headquarters, Microsoft was able to show NBC some ways it could do more using its homegrown Silverlight technology.

Silverlight, Microsoft said, would be key to enabling NBC’s vision of a “control room” in which a viewer could watch multiple live streams at once.

Perkins Miller, senior vice president, NBC Universal

(Credit: NBC)

Even within Microsoft’s team, though, there was some apprehension of whether it was doable.

“Can we actually pull this off?” Senior Technical Evangelist Jason Suess recalled thinking. “Is the user’s machine going to be able to maintain four connections at one time?”

The key, Suess said in an interview at Microsoft headquarters last week, is using an approach known as adaptive streaming in which the player has the ability to customize the bit rate of the video stream based on a computer’s connection and processing power.

By Valentine’s Day, they were ready for a test. It was pretty important that the test work out, given that NBC was getting ready to crate up the gear to ship it off to Beijing.

“That was the first time the player came to life,” Suess said. “Obviously the player was extremely crude.”

Making it pay
One of the last pieces to fall into place was the advertising. Initially, NBC and Microsoft were hoping to be able to insert full video ads into the live streams, but doing so is tough work.

“You don’t have any way to pause a live stream,” Suess said. “Trying to deliver a video ad on top of that, you hit the limits of a user’s bandwidth.”

As of mid-April, they were still struggling with what to do and began considering that perhaps they would have to just rely on companion advertising around the video stream. Then they came up with an idea. Rather than insert full videos into the live streams, what if they stuck a display ad into the video, particularly during dead times in the action.

Jason Suess, senior technical evangelist, Microsoft

(Credit: Ina Fried/CNET News)

That, approach, which is ultimately what’s being done, solved several issues. It was less bandwidth-intensive than video ads, but still got the advertiser directly in front of the viewer, all without interrupting any of the coverage. The amount of advertising will vary, Suess said; “It depends what is happening in the sports. We just wait for a dead space.”

By early May, NBC made the basic player available on the Internet, using a variety of prerecorded Olympic video, and by early June the enhanced Silverlight player was made public as well. The Olympic Trials, at the end of June, offered the companies and the public a chance for a test drive.

At this point, it’s come down to a triage of the few remaining known bugs. Each day, the bar is being raised in terms of what is a big enough deal to warrant such a late change. Suess, meanwhile, sent his wife and kids to visit family in New York so he could work 18-hour days.

In an interview last week, Suess said he had been at work until 1 a.m. the night before and gets in every morning by 8 a.m., so he can chat with the folks in Beijing before they sign off for the night.

“If I am not online and pushing things along, then I am introducing delay,” Suess said.

An admitted type-A personality, Suess is a stickler for organization–the kind of guy whose desk is always clean. (His wife would probably use the word “compulsive,” Suess said.)

Suess said he hopes things will be enough under control that he can actually watch some of the games, particularly sailing, of which he is a big fan. “I sure hope so,” he said. “When I got involved in this project, that was one of the reasons.”

The web is helping our children read more. Or less. Or, well, maybe it depends on what you call reading. Because if it’s got spelling mistakes or words no dictionary has caught up with yet, then it’s not really reading, is it?

The New York Times yesterday hosted a spirited debate on the subject. Parents, dyslexics, professors, even children chipped in with their muscular views. Subtly showing its hand, the Times made sure the article was a very long one. Because, like many other bastions of journalism and literature, it is a newspaper that chooses to uphold certain standards.

Standards that the immature denizens of Silicon Valley have not so much eroded, but positively assaulted with the deadly weapons of speed, ubiquity and a somewhat fetching disregard for antiquity.

Personally, I would rather be around someone who is curious about the world than someone who believes Mongolia is where retarded children come from. Can anyone truly dispute that the web has given people a greater and more immediate ability to hug a little knowledge?

So it seems that what many critics are concerned about is precisely the kind of knowledge and reading habits children acquire during a surfing expedition. Perhaps one thing the web has exposed is that some so-called works of literature are, frankly, verging on the really quite awful. Just as we have been hyped by burger chains and erectile malfunction cures, we have been hyped by literary guardians.

One tome is essential. Another is a lesser work. But so many are very hard work indeed. When you’re told something is fabulous and wonderful and stupendous, even when you find it not so, it isn’t so easy to declare your opinion.

(Look, I’m sorry, but Eugene O’Neill’s plays are turgid tripe. And don’t get me started on Chekov and James Joyce. There, that’s better.)

Perhaps there will soon come a time when reading a book for today’s 12-year-olds will be as arduous as picking up the tiniest Chaucer and seeing if you can get past page one. Just because one generation was inculcated into the 400-page habit doesn’t mean another can’t find its own way to learn, grow, feel and any other New Agey term you might wish to use to indicate some level of progression.

Deal with it, olds.

So you love Emily Bronte. That’s OK. Don’t blame yourselves. It doesn’t mean that should be anyone else’s idea of literature. Or art. Or knowledge. It can even be someone else’s idea of bilge. And they could be right. There again, of all the names a Google rival could have come up with to name their new brand, they find one that you have to learn how to pronounce and that is a mere consonant away from something very rude indeed.

Where did these people go to college? Chico State?

[response from Mat]

Yea, but sorry, I can list off a ton of truly great writers even if you don’t like O’Neill (which I agree with), Chekov (the only Russian writer I actually find dull), Joyce, Chaucer, or Bronte.

Forum Post: design or develop first?

Q: "just wondering if I should go about designing my site first before implementing any back end capabilities. i like to keep things organized and plan ahead. It would seem to make sense to create the static site first but i am somewhat unsure if I were to design first and end up redesigning to fit everything I plan on adding later, in terms of dynamic content."

R: "The approach you take probably depends on whether you are more of a designer or more a developer. A developer would tend to do the back end first without worrying too much about exactly how the page will look until after they know that it all functions properly. A designer would probably get the page looking exactly how they want and then worry about how to get it to function correctly. If you have separate people performing each of these tasks then all that needs to be done first is to define the interface between the two so that the two almost separate parts can be done separately in the knowledge that they will fit together once both are done."

Article: HTML or XHTML: Does It Really Matter? (excerpted, July 9, 2008 by James Edwards)

HTML was originally conceived as a semantic language, in which elements should describe only the meaning of their content, not the presentation. However, this good intention didn’t hold up very long.

In 1997, the HTML 4.0 specification was published, and although it continued to include presentational markup that had been instigated directly by vendors, it also began a push to clean up HTML, calling some markup “deprecated” and suggesting that it not be used.

XHTML 1.0 came along in 2000 as formalization of HTML 4 into XML. XML itself had been standardized in 1998 as a general specification for defining markup languages, and was a stricter and simpler offshoot of SGML, the Standard Generalized Markup Language from which HTML itself was originally derived.

XHTML is still worth using, because it’s a transitional standard that moves us towards a pure-XML Web. XML is inherently better than SGML, because it’s simpler and stricter, and much easier to parse (once you’ve understood its rules). I don’t know from where we’ve adopted the idea that we should be forgiving of markup errors, but I don’t share that view.

And some other choice reads:

• Custom Web Fonts: Pick Your Poison by Kevin Yank
• Fancy Form Design Using CSS by Cameron Adams
• 10 Tips for Being a Greener Web Designer by Matthew Magain

TIOBE Index, July 2008 by TIOBE bv

Position		Delta	Language	Ratings Jul 2008	Delta Jul 2007	Status
Jul 2008	Jul 2007
1	1		Java	21.345%	+0.33%	A
2	2		C	15.945%	-0.42%	A
3	3		C++	10.693%	+0.19%	A
4	4		(Visual) Basic	10.447%	+0.72%	A
5	5		PHP	9.525%	+0.87%	A
6	6		Perl	5.131%	-0.20%	A
7	8		Python	4.973%	+1.95%	A
8	7		C#	4.000%	+0.29%	A
9	9		JavaScript	2.757%	+0.24%	A
10	10		Ruby	2.735%	+0.64%	A

(For my students) In case you’re wondering why HTML is not included in this list, the definition used by the index is:

A language is considered a programming language if it is Turing complete. As a consequence, HTML and XML are not considered programming languages. This also holds for data query language SQL. SQL is not a programming language because it is, for instance, impossible to write an infinite loop in it. On the other hand, SQL extensions PL/SQL and Transact-SQL are programming languages. ASP and ASP.NET are also not programming languages because they make use of other languages such as JavaScript and VBScript or .NET compatible languages. The same is true for frameworks such as Ruby on Rails, ColdFusion, Cocoa, and technologies such as AJAX. Finally, we have also excluded assembly languages, although Turing complete, because they have a very different nature.

And finally, for those of you in my weekend classes…yes, it’s 2 hours after class and yes, I am still up.  Good night.

Blog Design Survey

We have identified 30 design problems and considered solutions for each of the problems separately. We have posed 30 questions which we would like to answer with our blog survey. Below we present findings of our survey of popular blog designs — the results of an analysis of 50 popular blogs according to Technorati’s Top 100.

Considering Technorati’s top 50, we have filtered out social networks and blogs which have artificially become popular — e.g. via backlinks in released Wordpress themes. The prize for the most cluttered CSS-code goes to Smashing Magazine — however, we are going to do something about it over the next weeks.

Please notice: the results presented below should not be considered as guidelines for an effective blog design. They are supposed to give you the intuition of which solution may be better than the other one. However, you need to consider the context you are working within as well — following our findings blindly won’t necessarily improve your design. Still it is useful to know what big players do and, more importantly, what they don’t do.

1. Layout

Let us start with the analysis of the layouts used on the most popular blogs in the blogosphere. Are there more 2-column-layouts than 3-column-layouts? Are layouts centered? Are they fixed, fluid or elastic? Are tables still used? In this section we are going to answer all these questions.

1.1. How many columns?

The question whether one should use 2 columns or 3 columns in a design layout is almost philosophical. Unfortunately, we weren’t able to find any results from usability studies which would prefer one solution over the other one. As usual, it depends on the context and on the target group you are dealing with. In some cases it is just impossible to find a proper balance between primary and secondary content with 2 columns. In these situations you may need to divide the second column (sidebar) into two parts — in fact this solutions is used quite often.

Read the rest of the article…

For example, let’s say that you’ve created a table to hold all of your users logins and passwords (and some other info):

CREATE TABLE users (
   userID INT NOT NULL IDENTITY(1,1),
   login NVARCHAR(32) NOT NULL,
   passw NVARCHAR(100) NOT NULL,
   email NVARCHAR(50) NOT NULL,
   uName NVARCHAR(50) NULL,
   uCreated SMALLDATETIME NOT NULL DEFAULT (getdate())
)

On the one hand you can simply write a simple query in your server-side script (here in ASP.NET):

string mySqlQuery = "SELECT * FROM users
   WHERE login = '" + strLogin + "' AND passw = '" + strPass + "'";

And that would work great.  But now lets say you’ve constructed a second table containing more normalized information about the user:

CREATE TABLE usersMetadata (
   userID INT NOT NULL DEFAULT (0),
   dataDescription NVARCHAR(50) NOT NULL,
   theInformation NVARCHAR(1000) NULL
)

So what if you wanted to pull certain information about a specific user?  Once again we can write a simple query:

string mySqlQuery = "SELECT usersMetadata.*,users.*
   FROM usersMetadata
   LEFT JOIN users ON users.userID = usersMetadata.userID
   WHERE userID = " + intUserId + " AND dataDescription = '" + strSomeInfo + "'";

And that would work great too.  But as those of us who develop large-scale web sites know, we re-use queries over and over, frequently.  So what happens when we change the query on one page and neglect to change it on another?  Now we have two pages with different results.  Not good.

Using a stored procedure, we now give ourselves direct access to a centralized query.  This means that if we change it once (on the server), it changes for all instances of it.  So how do we do this?  Writing a stored procedure is relatively simple. 

CREATE PROCEDURE dbo.getUserMetadata
   @userID INT,
   @dataType NVARCHAR(50)
SET NO COUNT ON
BEGIN
   SELECT usersMetadata.*,users.* FROM usersMetadata
   LEFT JOIN users ON users.userID = usersMetadata.userID
   WHERE userID = @userID AND dataDescription = @dataType
END

Calling stored procedures is a snap too. Instead of writing out the entire query, we can just execute the procedure as:

string mySqlQuery = "EXEC getUserMetadata @UserID, @dataType";

Note that we would declare the @ parameters as well

Stored procedures can also be great when you need to extrapolate data from multiple places and perform additional actions on the data before output.  Stored procedures, for example, allow you to create, use and destroy temporary tables of information without affecting the whole.  Say, for example you want to test how your data might react if performed but you don’t want it to go against the live table first.

CREATE PROCEDURE dbo.testUserUpdate
SET NO COUNT ON
BEGIN
   -- this is the temporary table
   CREATE TABLE #users (
      userID INT NOT NULL IDENTITY(1,1),
      login NVARCHAR(32) NOT NULL,
      passw NVARCHAR(32) NOT NULL,
      email NVARCHAR(50) NOT NULL,
      uName NVARCHAR(50) NULL,
      uCreated SMALLDATETIME NOT NULL DEFAULT (getdate())
   )
   -- inserts all users created in the last month to the temporary table
   INSERT INTO #users SELECT users.userID,login,passw,email,uName,uCreated FROM users
   WHERE uCreated > DATEADD('dd',-30,getdate())
-- apply some silly change like altering the password for any user with a login beginning with an a
UPDATE #users SET passw = 'KILLED-YOUR-PASSWORD' WHERE login LIKE 'a%'
   -- now display the data
SELECT * FROM #users ORDER BY #users.login
-- and be sure to destroy the temporary (it is temporary after all)
DROP TABLE #users
SET NOCOUNT OFF
END

This procedure will have the same basic effect as having made the update to the users table but instead applied it to transitory data that was destroyed before leaving the query. Now assuming that the results were good, you could ideally just have a second procedure to actually alter the original table.

Shortly we’ll add to this post with an update. In the meantime, code on!

This morning I spent 90 minutes in line with Jennifer waiting to buy her 3G.  I’m not quite sure what the fascination is with actually waiting in line that long (more than 7 hours all in all) to get one, but I’ll give her credit for persevering that long.  Now on the other hand, the Touch Pro will reportedly be out in September, so maybe I’ll eat my own words.  Unless I break down and import one instead.

I sat through an enlightening department meeting today in which the issue of, amongst other things, design came up.  Without going overboard I would like to elicit a challenge to all WDIM students this quarter not only to complete the work they are assigned but to challenge themselves one step further and "polish" your design. 

Mr. Anderson had an interesting point - a lot of you don’t seem to know where to begin and he gave out a lot of recommendations that I strongly agree with: stepping away from the computer and drawing by hand, layering screencaps of choice sites on top of each other in Photoshop and deconstructing or morphing them together, cutting clips from magazines and arranging them together like a scrapbook.  The point being that despite everyone’s creative talents, sometimes finding direction is the hardest part.  Take a step to be different.

From my end I would like to see more polish.  Hopefully we’ll be able to incorporate a few good example of what we mean by this in IMD345 (UCD3) this quarter.  Or if you need some examples, pick up Web Designer Magazine (a glossy, expensive British mag - find it at Barnes & Noble) and check out some of the great design coming out of the UK.  Aspire to get that kind of cleanliness or artistry in your design.  By the same token, don’t lose sight of the content and functionality.

See you next week!

Computer industry heavyweights are hustling to fix a flaw in the foundation of the Internet that would let hackers control traffic on the World Wide Web.

Major software and hardware makers worked in secret for months to create a software “patch” released on Tuesday to repair the problem, which is in the way computers are routed to web page addresses.

“It’s a very fundamental issue with how the entire addressing scheme of the Internet works,” Securosis analyst Rich Mogul said in a media conference call.  “You’d have the Internet, but it wouldn’t be the Internet you expect. (Hackers) would control everything.”  (more…)

And a response via Doxpara.

With an opening sentence that reads "If you want to maximize the revenue of your service you need to maximize completion rates of your web forms." it definitely has to be good.  Vitaly and Sven rarely disappoint and this is no exception.  Required reading for all UCD3 students (the entire article, not just this excerpt) this quarter so get a head start.

If you want to maximize the revenue of your service you need to maximize completion rates of your web forms. Unless you have some revolutionary ideas to impress your visitors at first glance, it is not enough to simply enable users to sign up on your site. To make it possible for the service to reach a maximal exposure we, designers, need to provide users with a good user experience. We need to invite them, describe them how the service works, explain them why they should fill in the form and suggests the benefits they’ll get in return. And, of course, we should also make it extremely easy for them to participate.

However, designing effective web forms isn’t easy. And it has one simple reason: nobody likes to fill in forms — neither offline nor online. Therefore, as designers, we need to figure out sound design decisions to make the form completion easy, intuitive and painless.

But how exactly can we figure out these decisions? Where should the link to the form be placed in the layout? How should we design it? How should we highlight the labels and how should we align them? How do web form design patterns look like in modern web-sites? These were exactly the questions we’ve asked ourselves. And to get the answers we’ve conducted a survey.

Below we present findings of our survey of current web form design patterns — the results of an analysis of 100 popular web-sites where web-forms (should) matter. We have decided to start with sign-up forms first. We present the first part of our findings below; the second part of the survey results will be published next week.

Read the rest at SmashingMagazine…

OK, back to studying.

No, I didn’t write this but it’s something I wish I could lay claim to.

1. Inability to reason about code

Reasoning about code means being able to follow the execution path ("running the program in your head") while knowing what the goal of the code is.

Symptoms

1. The presence of "voodoo code", or code that has no effect on the goal of the program but is diligently maintained anyway (such as initializing variables that are never used, calling functions that are irrelevant to the goal, producing output that is not used, etc.)
2. Executing idempotent functions multiple times (eg: calling the save() function multiple times "just to be sure")
3. Fixing bugs by writing redundant code that overwrites the result of the faulty code
4. "YoYo code" that converts a value into a different representation, then converts it back to where it started (eg: converting a decimal into a string and then back into a decimal, or padding a string and then trimming it)
5. "Bulldozer code" that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)

Remedies

To get over this deficiency a programmer can practice by using the IDE’s own debugger as an aide if it has the ability to step through the code one line at a time. In Visual Studio, for example, this means setting a breakpoint at the beginning of the problem area and stepping through with the ‘F11′ key, inspecting the value of variables–before and after they change–until you understand what the code is doing. If the target environment doesn’t have such a feature, then practice in one that does.

The goal is to reach a point where you no longer need the debugger to be able to follow the flow of code in your head, and where you are patient enough to think about what the code is doing to the state of the program. The reward is the ability to identify redundant and unnecessary code, as well as how to find bugs in existing code without having to re-implement the whole algorithm from scratch.

2. Poor understanding of the language’s programming model

Object Oriented Programming is an example of a language model, as is Functional or Declarative programming. They’re each significantly different from procedural or imperative programming, just as procedural programming is significantly different from assembly or GOTO-based programming. Then there are languages which follow a major programming model (such as OOP) but introduce their own improvements such as list comprehensions, generics, duck-typing, etc.

Symptoms

1. Using whatever syntax is necessary to break out of the model, then writing the remainder of the program in imperative/procedural style
2. (OOP) Attempting to call non-static functions or variables in uninstantiated classes, and having difficulty understanding why it won’t compile
3. (OOP) Writing lots of "xxxxxManager" classes that contain all of the methods for manipulating objects that have little or no methods of their own
4. (Relational) Treating the database as an object store, possibly going as far as serializing the state of the object to a binary column
5. (Functional) Creating multiple versions of the same algorithm to handle different types or operators, rather than passing high-level functions to a generic implementation
6. (Functional) Manually caching the results of a deterministic function
7. (Pure Functional) Using cut-n-paste code from someone else’s program to deal with I/O and Monads
8. (Declarative) Setting individual values in imperative code rather than using data-binding

Remedies

If your skills deficiency is a product of ineffective teaching or studying, then an alternative teacher is the compiler itself. There is no more effective way of learning a new programming model than starting a new project and committing yourself to use whatever the new constructs are, intelligently or not. You also need to practice explaining the model’s features in crude terms of whatever you are familiar with, then recursively building on your new vocabulary until you understand the subtleties as well. For example:

Phase 1: "OOP is just records with methods"
Phase 2: "OOP methods are just functions running in a mini-program with its own global variables"
Phase 3: "The global variables are called fields, some of which are private and invisible from outside the mini-program"
Phase 4: "The idea of having private and public elements is to hide implementation details and expose a clean interface, and this is called Encapsulation"
Phase 5: "Encapsulation means my business logic doesn’t need to be polluted with implementation details"

Phase 5 looks the same for all languages, since they are all really trying to get the programmer to the point where he can express the intent of the program without burying it in the specifics of how. Take functional programming as another example:

Phase 1: "Functional programming is just doing everything by chaining deterministic functions together"
Phase 2: "When the functions are deterministic, they don’t need to be executed until the output is called for, and only for as much as needed. This is called Lazy Evaluation and Partial Evaluation"
Phase 3: "In order to support Lazy and Partial Evaluation, the compiler requires that I write functions in terms of how to transform a single parameter, sometimes into another function. This is called Currying"
Phase 4: "When all functions are curried, the compiler can choose the best execution plan by using a constraint solver"
Phase 5: "By letting a constraint solver figure out the mundane details, I can write programs by describing what I want, rather than how to give it to me"

3. Deficient research skills / Chronically poor knowledge of the platform’s features

Modern languages and frameworks now come with an awesome breadth and depth of built-in commands and features, with some leading frameworks (Java, .Net, Cocoa) being too large to expect any programmer, even a good one, to learn in anything less than a few years. But a good programmer will search for a built-in function that does what they need before they begin to roll their own, and excellent programmers have the skill to break-down and identify the abstract problems in their task, then search for existing frameworks, patterns, models and languages that can be adapted before they even begin to design the program.

Symptoms

These are only indicative of the problem if they continue to appear in the programmer’s work long after he should have mastered the new platform.

1. Re-inventing or laboring without basic mechanisms that are built-into the language, such as events-and-handlers or regular expressions
2. Re-inventing classes and functions that are built-into the framework (eg: timers, collections, sorting and searching algorithms) *
3. "Email me teh code, plz" messages posted to help forums
4. "Roundabout code" that accomplishes in many instructions what could be done with far fewer (eg: rounding a number by converting a decimal into a formatted string, then converting the string back into a decimal)
5. Persistently using old-fashioned techniques even when new techniques are better in those situations (eg: still writes named delegate functions instead of using lambda expressions for one-offs)
6. Having a stark "comfort zone", and going to extreme lengths to solve complex problems with primitives

* - Accidental duplication will also happen, proportionate to the size of the framework, so judge by degree.

Remedies

A programmer can’t acquire this kind of knowledge without slowing down, and it’s likely that he’s been in a rush to get each function working by whatever means necessary. He needs to have the platform’s technical reference handy and be able to look through it with minimal effort, which can mean either having a hard copy of it on the desk right next to the keyboard, or having a second monitor dedicated to a browser. To get into the habit initially, he should refactor his old code with the aim of reducing its instruction count by 10:1 or more.

4. Inability to comprehend pointers

If you don’t understand pointers then there is a very shallow ceiling on the types of programs you can write, as the concept of pointers enables the creation of complex data structures and efficient APIs. Managed languages use references instead of pointers, which are similar but add automatic dereferencing and prohibit pointer arithmetic to eliminate entire classes of bugs. They are still similar enough, however, that a failure to grasp the concept will be reflected in poor data-structure design and bugs that trace back to the difference between pass-by-value and pass-by-reference in method calls.

Symptoms

1. Failure to implement a linked list, or write code that inserts/deletes nodes from linked list without losing data
2. Allocating arbitrarily big arrays for variable-length collections and maintaining a separate collection-size counter, rather than using a linked list or other dynamic data structure
3. Inability to find or fix bugs caused by performing arithmetic on pointers
4. Modifying the dereferenced values from pointers passed as the parameters to a function, and not expecting it to change the values in the scope outside the function
5. Making a copy of a pointer, changing the dereferenced value via the copy, then assuming the original pointer still points to the old value
6. Serializing a pointer to the disk or network when it should have been the dereferenced value
7. Sorting an array of pointers by performing the comparison on the pointers themselves

Remedies

A friend of mine named Joe was staying somewhere else in the hotel, but I didn’t know which room number. I did, however, know which room his acquaintance, Frank, was staying in. So I went up there and knocked on his door and asked him, "Where’s Joe staying?" Frank didn’t know, but he did know which room Joe’s co-worker, Theodore, was staying in, and gave me that room number instead. So I went to Theodore’s room and asked him where Joe was staying, and Theodore told me that Joe was in Room 414. And that, in fact, is where Joe was.

Pointers can be described with many different metaphors, and the data structures you can build translated into many analogies. The above is a simple analogy for a linked list, and anybody can invent their own, even if they aren’t programmers. The comprehension failure doesn’t occur when pointers are described, so you can’t describe them any more thoroughly than they already have been. It fails when the programmer then tries to visualize what’s going on in the computer’s memory and it gets conflated with their understanding of regular variables, which are very similar. It may help to translate the code into a simple story to help reason about what’s going on, until the distinction clicks and the programmer can visualize pointers and the data structures they enable as intuitively as scalar values and arrays.

5. Difficulty seeing through recursion

The idea of recursion is easy enough to understand, but programmers often have problems imagining the result of a recursive operation in their minds, or how a complex result can be computed with a simple function. This makes it harder to design a recursive function because you have trouble picturing "where you are" when you come to writing the test for the base condition or the parameters for the recursive call.

Symptoms

1. Hideously complex iterative algorithms for problems that can be solved recursively (eg: traversing a filesystem tree), especially where memory and performance is not a premium
2. Recursive functions that check the same base condition both before and after the recursive call
3. Recursive functions that don’t test for a base condition
4. Recursive subroutines that concatenate/sum to a global variable or a carry-along output variable, and aren’t implementing tail recursion
5. Apparent confusion about what to pass as the parameter in the recursive call, or recursive calls that pass the parameter unmodified

Remedies

Get your feet wet and be prepared for some stack overflows. Begin by writing code with only one base-condition check and one recursive call that uses the same, unmodified parameter that was passed. Stop coding even if you have the feeling that it’s not enough, and run it anyway. It throws a stack-overflow exception, so now go back and pass a modified copy of the parameter in the recursive call. More stack overflows? Excessive output? Then do more code-and-run iterations, switching from tweaking your base-condition test to tweaking your recursive call until you start to intuit how the function is transforming its input. Resist the urge to use more than one base-condition test or recursive call unless you really know what you’re doing.

Your goal is to have the confidence to jump in, even if you don’t have a complete sense of "where you are" in the imaginary recursive path. Then when you now need to write a function for a real project you’d begin by writing a unit test first, and proceeding with the same technique above.

Signs that you are a mediocre programmer

1. Inability to think in sets

Transitioning from imperative programming to functional and declarative programming will immediately require you to think about operating on sets of data as your primitive, not scalar values. The transition is required whenever you use SQL with a relational database (and not as an object store), whenever you design programs that will scale linearly with multiple processors, and whenever you write code that has to execute on a SIMD-capable chip (such as modern graphics cards and video game consoles).

Symptoms

The following count only when they’re seen on a platform with Declarative or Functional programming features that the programmer should be aware of.

1. Performing atomic operations on the elements of a collection within a for or foreach loop
2. Writing Map or Reduce functions that contain their own loop for iterating through the dataset
3. Fetching large datasets from the server and computing sums on the client, instead of using aggregate functions in the query
4. Functions acting on elements in a collection that begin by performing a new database query to fetch a related record
5. Writing business-logic functions with tragically compromising side-effects, such as updating a user interface or performing file I/O
6. Entity classes that open their own database connections or file handles and keep them open for their lifespan

Remedies

Funny enough, visualizing a card dealer cutting a deck of cards and interleaving the two stacks together by flipping through them with his thumbs can jolt the mind into thinking about sets and how you can operate on them in bulk. Other stimulating visualizations are:

• freeway traffic passing through an array of toll booths (parallel processing)
• springs joining to form streams joining to form creeks joining to form rivers (parallel reduce/aggregate functions)
• a newspaper printing press (coroutines, pipelines)
• the zipper tag on a jacket pulling the zipper teeth together (simple joins)
• transfer RNA picking up amino acids and joining messenger RNA within a ribosome to become a protein (multi-stage function-driven joins, see animation)
• the above happening simultaneously in billions of cells in an orange tree to convert soil, water and sunlight into orange juice (Map/Reduce on large distributed clusters)

If you are writing a program that works with collections, think about all the supplemental data and records that your functions need to work on each element and use Map functions to join them together in pairs before you have your Reduce function applied to each pair.

2. Lack of critical thinking

Unless you criticize your own ideas and look for flaws in your own thinking, you will miss problems that can be fixed before you even start coding. If you also fail to criticize your own code once written, you will only learn at the vastly slower pace of trial and error. This is the root of lazy thinking and egocentric thinking, so its symptoms seem to come from two different directions.

Symptoms

1. "Business Rule Engines"
2. Fat static utility classes, or multi-disciplinary libraries with only one namespace
3. Conglomerate applications, or attaching unrelated features to an existing application to avoid the overhead of starting a new project
4. Architectures that have begun to require epicycles
5. Adding columns to tables for tangential data
6. Inconsistent naming conventions
7. "Man with a hammer" mentality, or changing the definitions of problems so they can all be solved with one particular technology
8. Programs that dwarf the complexity of the problem they solve
9. Pathologically and redundantly defensive programming ("Enterprisey code")

Remedies

Start with a book like Critical Thinking by Paul and Elder, work on controlling your ego, and practice resisting the urge to defend yourself as you submit your ideas to friends and colleagues for criticism.

Once you get used to other people examining your ideas, start examining your own ideas yourself and practice imagining the consequences of them. In addition, you also need to develop a sense of proportion (to have a feel for how much design is appropriate for the size of the problem), a habit of fact-checking assumptions (so you don’t overestimate the size of the problem), and a healthy attitude towards failure (Isaac Newton was wrong about gravity, but we still love him and needed him to try anyway).

Finally, you must have discipline. Being aware of flaws in your plan will not make you more productive unless you can muster the willpower to correct and rebuild what you’re working on.

3. Pinball Programming

When you tilt the board just right, pull back the pin to just the right distance, and hit the flipper buttons in the right sequence, then the program runs flawlessly with the flow of execution bouncing off conditionals and careening unchecked toward the next state transition.

Symptoms

1. One Try-Catch block wrapping the entire body of Main() and resetting the program in the Catch clause (the pinball gutter)
2. Using strings/integers for values that have (or could be given) more appropriate wrapper types in a strongly-typed language
3. Packing complex data into delimited strings and parsing it out in every function that uses it
4. Failing to use assertions or method contracts on functions that make assumptions about their arguments
5. The use of Sleep() to wait for another thread to finish its task
6. Switch statements, on non-enumerated values, that don’t have an "Otherwise" clause
7. Using Automethods or Reflection to invoke methods that are named in unqualified user input
8. Setting global variables in functions as a way to return multiple values
9. Classes with one method and a couple of fields, where you have to set the fields as the way of passing parameters to the method
10. Multi-row database updates without a transaction
11. Hail-Mary passes (eg: trying to restore the state of a database without a transaction and ROLLBACK)

Remedies

Imagine your program’s input is water. It’s going to fall through every crack and fill every pocket, so you need to think about what the consequences are when it flows somewhere other than where you’ve explicitly built something to catch it.

You will need to make yourself familiar with the mechanisms on your platform that help make programs robust and ductile. There are three basic kinds:

1. those which stop the program before any damage is done when something unexpected happens, then helps you identify what went wrong (type systems, assertions, exceptions, etc.),
2. those which direct program flow to whatever code best handles the contingency (try-catch blocks, multiple dispatch, event driven programming, etc.),
3. those which pause the thread until all your ducks are in a row (WaitUntil commands, mutexes and semaphores, SyncLocks, etc.)

There is also a fourth, Unit Testing, which you use at design time.

Using these ought to become second nature to you, like putting commas and periods in sentences. To get there, go through the above mechanisms (the ones in parenthesis) one at a time and refactor an old program to use them wherever you can cram them, even if it doesn’t turn out to be appropriate (especially when they don’t seem appropriate, so you also begin to understand why).

Signs that you shouldn’t be a programmer

The following may not have any remedies if you still suffer from them after taking a programming course in school, so you will stand a better chance of advancing your career by choosing another profession.

1. Inability to determine the order of program execution

Symptoms

a = 5
b = 10
a = b

print a

1. You look at the code above and aren’t sure what number gets printed out at the end

Alternative careers

1. Electrician
2. Plumber
3. Architect
4. Civil engineer

2. Insufficient ability to think abstractly

Symptoms

1. Difficulty comprehending the difference between objects and classes
2. Difficulty implementing design patterns for your program
3. Difficulty writing functions with low cohesion
4. Incompetence with Regular Expressions
5. Lisp is opaque to you
6. Cannot fathom the Church-Turing Thesis

Alternative careers

1. Contract negotiator
2. Method actor

3. Collyer Brothers syndrome

Symptoms

1. Unwilling to throw away anything, including garbage
2. Unwilling to delete anything, be it code or comments
3. The urge to build booby-traps for defense against trespassers
4. Unwilling to communicate with other people
5. Poor organization skills

Alternative careers

1. Antique dealer
2. Bag lady

4. Dysfunctional sense of causality

Symptoms

1. You seriously consider malice to be a reason why the compiler rejects your program
2. When called on to fix a bug in a deployed program, you try prayer
3. You take hidden variables for granted and don’t think twice about blaming them for a program’s misbehavior
4. You think the presence of code in a program will affect its runtime behavior, even if it is never invoked
5. Your debugging repertoire includes rituals like shining your lucky golf ball, twisting your wedding ring, and tapping the nodding-dog toy on your monitor. And when the debugging doesn’t work, you think it might be because you missed one or didn’t do them in the right order

Alternative careers

1. Playing the slot machines in Vegas

5. Indifference to outcomes

Programming could still be a hobby for you, but it would be in society’s best interests to defend itself against your entry into the world of professional software development.

Symptoms

1. You aren’t interested in fixing a bug that can be worked around by rebooting the computer
2. Your installation program silently deploys unsolicited third party programs that are unrelated to the function of yours *
3. You don’t use any ergonomic model when designing user interfaces, nor do you have any interest in usability studies
4. Your program exhibits pretension and grandeur beyond its utility, eg: displaying splash screens over active programs while loading in the background, or placing m