Towards Plato's Real World

We as product managers (should) have a platonistic ideal of what our product should be in its perfect, final state. This ideal is what drives us to improve our product and guides us in choosing which improvements to make first. The problem is that our ideal actually exists in Plato's Material World; that is to say, what we consider to be the perfect conception of our product is actually a shadow of what our product should really be if we were able to glimpse it as it exists in Plato's Real World.

The question then becomes: how do we steal that glimpse? Obviously we need to know what our product should be in order to improve on what it currently is; but who or what will allow us to gain that knowledge?

Only our customers are able to glimpse our product as it exists in Plato's Real World.

As our customers use our product, they have these flashes; these glimpses of the good and the bad of our product. They know, instinctively, what they want from our product; and they know where our product is exceeding, meeting or failing to meet their expectations. There is a problem, though: out customers are not able to communicate to us what they saw in the Real World. What our customers tell us when we ask them the questions "What do you think of this feature?" or "How would you change this product to make it ideal for you?" still exists in the Material World.

We are a step closer to learning about te Real World -- we know "who" will help us learn about our ideal product; but how can we steal our glimpse if our customers are unable to describe what they saw in the Real World without their explanation being corrupted by the Material World?

The only way to truly see how our product exists in its ideal form in the Real World is by capturing customer data while they are interacting with our product; not before; not after.

It is only during this magical moment when our users use our product that they are able to bridge the gap and give us a glimpse into how our product exists in the Real World. It's like a dream where, upon waking, it is hard to distinguish between what happened in the dream and what is real. They may truly believe something about your product, but until you have hard data from usage, you cannot really know.

This intuitively makes sense, doesn't it?

• Don't ask users if they would use a feature: see if they use it!
• Don't ask them if the placement of a call to action is effective: see if users are converting.
• Do ask them what they think they think the product is missing, but don't take that to mean that they will actually value the feature once it is implemented.

So here is to us listening to our customers -- please, listen to your customers -- but keeping in mind that both we and our customers are stuck trying to perceive the ideal product from the Material World perspective. And here is to us observing our customers using our product in order to steal that elusive glimpse into the Real World which allows us to see how our product exists in its ideal state.

Needing to Scale is a Good Problem to Have

I just finished listening to Scale at Facebook from InfoQ QCon 2010 where Aditya Agarwal (Director of Engineering at Facebook) discusses the layers that make up Facebook and where/how their content is stored, retrieved, aggregated, and presented.

This was an excellent talk, not only because Aditya gave good explanations of both the problems and the solutions that Facebook has worked through, but because he repeatedly emphasized: needing to scale is a good problem to have.

One of my favourite examples of this concept from this talk was Facebook Photos. When they launched Photos in May 2006, they created a solution that was quick, lean, and allowed for iterative improvement in the future; they did not over-architecture the solution.

As a result, they were able to launch Photos in 2 months which they considered to be a great competitive advantage.

They could not have predicted, in advance, how well this feature would be adopted. I remember when Photos came out -- I found it a bit strange, because that was not how I was currently using Facebook at the time. In fact, my first Photo album, "important things to remember", contains this image of colours that allowed me to test the "in this photo" tagging (you over over the colours and you are given their names). That is how seriously I took the feature at the time.

However, within 3 months, the Photos feature was so widely-used that it was time for a rewrite. Spending 2 months on a solution that lasted 3 months may seem like "waste", but consider which is the larger waste: 2 months to test a product in the market, before your competitors, with the option to iterate and improve later; or more than 2 months to over-architect a solution for a product that you do not know -- for sure -- will be adopted.

Yes, there is the ideal middle-ground where in a perfect world you know exactly how many users will adopt your product and thus spend an appropriate amount of development time scaling the issue; however, from my experience, marketing tends to over-estimate product adoption rates as often as developers tend to over-architect solutions.

The question then becomes: which would you rather have? Over-architected? Or under-architected? To echo Aditya's sentiments: needing to scale is a good problem to have.

Leave No Trace Programming

I just finished listening to the recording of Robert C. Martin's talk at QCon 2010 London. Martin offers a fresh look at code maintenance as a parallel to the Boy Scout's "Leave things better than you found them" motto: every time you added functionality to your code-base, you also do a small bit of refactoring and leave it slightly better than it was before your change.

I looked up the Boy Scouts of America's Leave No Trace training module and found some other interesting parallels when I substituted "camping" and "the outdoors" with "coding" and "your code-base". For example, here is a paragraph I have modified from the original text:

Leave No Trace Programming principles are not about restrictions; they are about responsible enjoyment of our code-base. Leave No Trace is not a simple program for coding; it is a way of life —- and learning Leave No Trace concepts begins with our own subject matter areas. The principles apply in our own area of ownership and our team's area of ownership as much as in the entire code-base. We should all practice Leave No Trace in our design and implementation, whatever area of the code-base we touch.

What exactly the tenets of Leave No Trace Programming are, I have yet to decide and may leave for another post.

All the same, I would recommend you check out his talk. There are a few areas that I find unnecessary (he spends some time throwing out numbers for "good lengths" of functions and classes which I wish had been edited out), but overall I found it to be worth the hour of my time.

Rambo Learns Quickly

The Pragmatic Programmer: From Journeyman to Master

Develop software in a way that lets you learn and respond quickly

I cannot fathom working in a software shop where you gather requirements, disappear into your cubicle for a year, and come out with the product. Duh! That product was *so* last year!

Getting something out there and learning quickly is key to successful software development. "Good software today is better than great software tomorrow" almost sums it up. It is missing one part of the equation: learning.

If you have good software today and you want to have great software in the future, how do you get there? What is your road map? A clue: data. Whether that data be customer feedback or (as is oft the case on our team) user data -- you should make *as few decisions as possible* until you have data to back them up.

If you are able to deliver fast, you are able to begin to gather knowledge sooner than if you had waited to deliver. To gather knowledge, though, you have to:

1. Have a general idea of what data you want to look at
2. Have a way to find and analyze that data

If you were to deploy software without any logging, how would you know how it is being used? If you were to deploy software without sending error reports, how would you know when things are going incorrectly?

In "Journeyman to Master" they discuss "Tracer Software". Their point is that when shooting a machine gun you can spend your time analyzing environmental variables (which, they contend, will likely change over time) and calculating the trajectory of the bullets based on that information (which is alot of up-front work that has not yet helped you hit your target) ...

... or you can pseudo-aim and fire. In machine guns they have tracer ammunition [wikipedia.org] that allow a human eye to detect where their stream of bullets is hitting: "ready, fire, aim."

This of course does *not* mean that you should fire as soon as you grab the gun, then turn around until you see your target. What it means is that once you have a good idea of where your target is, you do not waste any more time on finding the perfect way to reach that target; you start firing, and correct your aim thereafter.

In software development, this means that you do not find the perfect solution. You gather the basic requirements from the user, prioritize (find the general area of your target), and get something out that they can see in order to help you correct your aim to hit the target. That "something" is what Pragmatic Programmers call "tracer software".

So here is to us spending less time like physicists and more like Rambo: First Blood Part II.

Disclaimer: the Rambo method does not apply in all situations. Some situations may indeed require the services of a sniper. In those situations you should follow the correct protocol which (if I have learned anything from movies, which I obviously have) goes something like "ready, aim, aim some more, confirm your aim, confirm your target, confirm you have permission to fire, fire, confirm the target was hit, have someone else confirm the target was hit." Or something like that.

They think that your early ending
Was all wrong
For the most part theyre right
But look how they all got strong
Thats why I say hey man nice shot
What a good shot man
  -- Hey Man, Nice Shot by Filter

DISS: Do It Simple, Stupid!

Implementing Lean Software Development: From Concept to Cash

Do it simply, quickly, and learn. Then go back and do it again.

Reading the "Quality" chapter in "Implementing Lean" book (our Tech Bible), I was really trying to overlay their prescribed development cycle over our recent projects, and see what things would be like if we had followed their prophecies to the letter.

Step One: Write Tests

We would be using TDD in a religious fashion. They begin each user story by writing test cases that need implementation in order to pass. We tend to write test cases as things start solidifying or (in the case of our Selenium tests (read: regression tests) we write them after customer delivery). In my next projects, I will be using TDD to see how it really works in our environment. More on that later.

With black-box testing (which, let's face it, is what you are doing in TDD), you have to think of not only the cases where "it should work", but also the cases where "it should not break". Very different. That is a challenge that I have had with Black Boxing -- you have to be very careful to think (read: pre-imagine) the different harsh treatment that your software will be enduring down the road. Suffice to say, it is *very* important that your TDD takes into account what you *don't* want your system to do as much as what you *do* want it to do.

Step Two: Solve in the Simplest Way

We would do the simplest thing possible to get the test cases passing. The idea is, if you write your tests cases correctly, then when they pass you are theoretically done.

A main component of Lean Development is "Delivering Fast". The faster your code is out there, the faster you can learn from it. The more knowledge you have, the better decisions you can make. Delivering Fast does necessarily mean making reckless decisions. Martin Fowler's Technical Debt Quadrant should help illustrate the concept that:

It is OK to Incur Technical Debt, *IF* it is Prudent

Delivering Fast means that you incur Deliberate, Prudent debt in order to gain the most knowledge the most quickly. Which leads to...

Step Three: Refactor

After "going into the hole", technically, you need to clean up after yourself so that it is obvious what the code is meant to do, and how it is meant to do it *and* so you do not have to pay interest on that debt down the road.

Martin Fowler's idea of Prudent, Inadvertent debt is a long term concept, where you do not necessarily even notice the interest you are paying until long after you took out the loan. This is not the situation that warrants immediate refactoring. Rather, it is the Prudent, Deliberate debt that you need to pay down. Let me say this, though:

Do not attempt Step Three without having done Step One

If you do not have good testing in place, refactoring can be both tedious and dangerous. And it is not supposed to be! Refactoring is supposed to be a no-sweat, "Now I see that this will be much easier to work with if we do it like this", post-learning experience. It should not be a "I hope I did not break something" experience.

The reason that The R Word is shunned in so many workshops is because they have legacy (read: un-tested) code. I know: I currently work in one!

Personal Take-Aways

I personally am admittedly, chronically, and (perhaps?) notoriously infamous for over-engineering situations. Some might call it a lack of common sense. Some might call it a dull Occam's Razor. Some might call it not "Seeing the Whole"

This means that I often fall into a trap that could be avoided by printing out this concept from the Implementing Lean book and taping it to my monitor:

Do it Simple *Then* Refactor!

How many times have you gone in to implement a user requirement and seen an opportunity for refactoring. So as you are implementing, you are refactoring with the "future implementation" in mind. And how many times have you realized, during this process, that you did not foresee a technical difficulty? And what does that mean: that neither your implementation nor your refactoring can proceed. Everything has to be reverted, and you have to go down the one-at-a-time path anyways. So start one-at-a-time from the very beginning!

So here's to doing the simple thing the first time. And to learning from it. And to cleaning things up when the situation warrants it.

Do it Simple, Stupid!

Hey what would it mean to you?
To know that it'll
Come back around again
Hey whatever it means to you
Know that everything
Moves in circles
  -- "Circles" by Incubus

Broken Windows

The Pragmatic Programmer: From Journeyman to Master

In considering our codebase, we must realize that we *always* have to be proactive in guarding against code rot.

The more we touch a certain piece of code, the more susceptible it is to degradation. For new developers coming into our codebase -- or indeed, for existing developers simply seeing a new section of the code for the first time -- the feeling can sometimes be overwhelming. Legacy paths are so brittle and so entwined that you can spend a good chunk of time stepping through just to make sure you understand correctly what is going on. By the end of this process, you have seen enough to realize that these objects are in very poor shape, but (since they are legacy and not well tested), you feel almost powerless to fix them.

Surely it was not always this way. 8 years ago, when these legacy objects were being created, I believe that there must have been a sense of design and of "seeing of the whole" that was lost as:

1. the original developers moved on -- either to different opportunities or to managerial roles -- so there were less people seeing the whole
2. the "whole" got alot bigger and became more difficult to see
3. n-th generation developers did not take the time to try to see the whole

The "Broken Window Theory" of software development proposes that once we start letting certain aspects of our codebase sit around with obvious flaws or we let Technical Debt build up, we will see an exponential decay of quality as developers make changes. This is based off the premise that if you do not keep a clean house, others are less likely to clean up after themselves.

With Broken Windows, the keyword is "care". Once you hit a certain level of disrepair, people kind of say "Fuck it" and just make their h4x changes. Hooligans. That's equivalent to throwing another rock through the building's few-remaining windows.

Instead, we should be like a frog being dropped into hot water. We should immediately say "wait a minute, that's really, really shitty" and raise that flag to Stop the Line. We not only have the authority, we have the responsibility. Besides, if you have legacy objects then you need to realize that your ability to respond quickly will be inversely related to how important those objects are -- so test them! And if you need to make changes to a tested object, you're covered! (no pun intended)

So here's to us being less like hooligans -- who contribute to the problem because they do not feel the responsibility to contribute to the solution -- and more like ... Japanese Auto Workers? Raise the issue, make the changes, and hopefully you will save:

1. future developers from massive confusion
2. future code aborts from undetected defects
3. and future broken windows, since developers are less likely to get mud on the carpet if it has obviously been cleaned recently

Once again, we are hungry for a lynching
That's a strange mistake to make
You should turn the other cheek
Living in a glass house
 -- Life in a Glass House by Radiohead

Black Listing

I'm not just saying this because modern society might say this is wrong -- I'm saying this because I think that there is a better way !

So I am currently the lead of this API . Recently we have had this influx of mailinator.com accounts signing up . The fact that 100% of these have occurred in the last 2 weeks (out of multiple years of operations) lends to the fact that these are all the same person .

Our API has daily limits ... and by signing up for multiple accounts, this (these? can't be too sure) developers are essentially bypasing those checks.

But I do not care about the limits ! They are entirely arbitrary ! I could just as soon multiply them by a factor as ten . They exist to differentiate the Developers from the Partners . If you are using our API in such a way that you require more requests per day than is the default, we would like to talk with you.

And most of the time this happens . We make it clear that we have limits, and that we are very willing to discuss with you the raising of those limits (do not read: razing) . We encourage this interaction, because it benefits both parties (hell, we often have paying partnership deals if we think it is in our best interest to incentivize you to drive traffic to our site) .

So why do people sign up for multiple accounts with throw-away email addresses ?

Well, from their perspective, they might just see this signup as just another spam well. A burden rather than a communication channel (does anyone else besides me have a ".trash" or ".spam" version of their email address ?) Or they believe we as an API team are detached from our product.

And that is our fault . If we made it apparent to the Developers that 1) we do not spam this address 2) we will only be using this address for important communications and 3) we are available ... then I do not think that we would have this issue of throw-away addresses .

So we could blacklist mailinator.com addresses. But then how hard is it to register for a new Yahoo! address? Where does it end?

No, the correct approach (in our situation) is better communication. A higher emphasis on the interaction between Developers and our API team.

This is how it works
You're young until you're not
You love until you don't
You try until you can't
You laugh until you cry
You cry until you laugh
And everyone must breathe
Until their dying breath
-- "On the Radio" by Regina Spektor

Google Barcode

Unless they were extremely slow before, the top Google results for "barcode generator"s must be experiencing an inane amount of traffic recently (http://twitpic.com/kkilx) .

Hopefully Google pre-thought to help them with this flux (http://twitpic.com/kkjmz).

Talk about the Slashdot Effect!

Why man, he doth bestride the narrow world
Like a Colossus, and we petty men
Walk under his huge legs and peep about
To find ourselves dishonorable graves
  -- Cassius, Julius Caesar, Act 1, Scene 2

Megalomania (User Votes)

In small online communities, I feel it's safer to allow people to over-vote than to under-vote.

I feel that if I am directed to a small site or blog which has some sort of "I liked this" voting mechanism I am doing them and their community the great service of taking a second of my time to give back to them (after having spent minutes reading or watching the proffered content and giving them advert revenues). Please, let me give you some money.

However, most-if-not-all sites essentially scold me. That is, they make me sign up (ugh) in order to further their site and its content -- they make me go through an unnecessary and tedious process (which I will probably regret later when I keep receiving emails from them) in order for ME to give THEM MY VALUABLE DATA. (If you don't think that data is valuable well, then ... dot dot dot).

Instead, we as web developers should be BEGGING for people's input at every opportunity we can get -- kind of like those "Who's butt is this? J-Lo's? Brad Pitt's?" flashing adverts.

And for all of you right-wing DB Admins: yes, I agree: it's a horrible suggestion: a row without a userid; however, Machine Learners would argue that userid or not, it's still valuable data and we shouldn't limit our inputs only to the "elite" (who have already signed up) or the "gullible" (who will agree to sign up so they can give us money).

The next time you are going to use some web-two-oh popup modal to require a guest (notice the difference between "customer" or "page hit") to "Login or Signup", think about what the USER is giving back to YOUR SITE and decide if it's really necessary.

In my opinion, until you get to the scale that digg.com was 3 years ago and the impact that voting makes on their site, don't assume that someone is trying to game your system -- or that it matters even if they are.

Hell, Codding Horror can use the same captcha and get away with it.

Pavlov's Bitch

I was recently beta-testing a friend's new site DevGrow which on one page had a checkbox labeled "Monitor Topic". After clicking it (and, being from the good ol' web days with no version number), I then faithfully searched the surrounding area and then the entire page for a "perform this action" button -- and never found it. Frustrated, I looked back up at the checkbox which now read "Monitoring Topic".

Yello?? Im in ur website bein lawst.

My original point of this post (sadly, not devgrow or basecamp) was Google: have you noticed when using GMail that clicking "Select [All | None | etc]" button that the (un)checking of your messages is wicked fast? I feel like I did something -- just by clicking a checkbox! Talk about positive reinforcement!

They might have realized (an acted on the fact that) this 'check-all' action is an important operation to the user and thus might have decided to speed up this action.

All that to say -- anticipating and responding to those parts of your website can provide the user with a pleasant (and let's not forget reinforcing) experience -- especially in the case of DHTML.

So here's to yellow or blue or whatever frickin' COLOR FADES; and to OBVIOUSLY different text changes; and to ICON changes; and to ANY changes BEFORE the async response. Because my life is very non-async. err. in sync. synchronized.

I smell you on my hand for days
I can't wash away your scent
If I'm a dog then you're a bitch
I guess you're as real as me
Maybe I can't live with that
Maybe I need fantasy
A life of chasing butterfly
-- Weezer - Butterfly

Computer DNA

We've all taken Biology classes and have been subjected to the memorization and regurgitation of the composition, structure, and behaviour of our physical shells -- base pairs, construction of proteins, metaphase, etc. This low-level view -- though incredibly interesting and insightful -- became incredibly tedious: while studying I ceased thinking of the effects of this miracle of life and was entirely engrossed in its technicalities.

In retrospect, I find DNA Biologists to be equatable to those of our breed who enjoy using ML, ASM, and (gasp) C in their everyday occupation. And I'm very grateful to both professions ! But I'm not sure what I would do if I had to consider either the protein breakdown of my sandwich or the hash-function in my VB.NET hashtable -- both are a necessarily abstracted into 'eating' and 'storing'.

This is not a new concept -- abstraction is necessary (anyone find a link?) facet of functioning.

All that to say -- I'm glad to have studied both Biology and ASM -- but I'm even more glad that I don't have to consider it every day. All the more for those who (choose?) do.

Appropriate ness (part deux)

I recently did a design review where there was an issue surrounding their choice of 'data storage implementation'. I use quotes because to me as a web developer, any data belongs in a database.

The issue arose over the fact that for this application written for the Java environment, they didn't need to store anything but usernames and passwords. They planned on using JDBC and having just one users table.

Like I said -- all well and good by me. I'm more used to having more tables and more relations between my data, but again it seemed most natural to me.

The surprise came when someone suggested that they just use a plain text file. If they were only going to store limited amounts of data and very very limited associations, why not just plain text?

Maybe this seems obvious to those who have had this experience before (or more than once), but it seemed so obvious to me that it was obscured. After the fact, it was indeed the right choice. Case to point: 1) Java has built in I/O operations 2) Their I/O operations would not (conceivably) cause any buildup and (most importantly) 3) JDBC is yet another thing to implement and (potentially) cause errors in their system.

Call me crazy but that Occam's Razor is either a natural talent or a life-long quest. For me it seems the latter.

So here's to other people's insightful (yet sometimes humiliating) comments that make our lives that much less complicated.

Appropriate ness (Appropriation?)

I recently did a constraint-satisfaction problem (CSP) in LISP to solve sudoku puzzles. I finally was able to visualize the recursive pattern and (to me) it looked alot like the stock market circa 1998-2005 -- up-down-up-down-down-up-up-down-down-down-down-up-up-down-up-up...

This actually reminded me of Matt Zandstra's book PHP 5 Objects, Patterns, and Practice. I read this at a time in my life where I had (naively) written an architecture for a system (in PHP5) which was quickly becoming unmanageable. This book helped me collect my thoughts about how to re-collect my code.

One of the things that I found very interesting which had never blipped on my radar was the idea of the appropriate throwing, catching, handling, and re-throwing of exceptions. Matt Zandstra emphasized that exceptions are powerful error-recovery tools -- but that they need to be handled at the appropriate level in your application: that model-level exceptions must be caught and handled (hopefully recovered) in the model and -- only when necessary -- passed controller. Heaven forbid if they propagate to the view.

Chris Snyder's book Essential PHP Security chimes in with the idea that often errors which occur at lower levels can cause security breaches. How many sites have you visited that have said "Cannot select `id` from table `users` with value ....". So if i just tweak this input-field...

So think about exceptions and their course through your application -- are there some which are relevant only to the model? Or are some worthy of propagating all the way up to your controller? Who owns that exception? Where does the buck stop?

User Expectations (part deux)

It's strange how the current generation (don't get me started on the following generation) has become accustomed to certain expectations for software. CTRL-C should *always* mean "I want to take whatever is selected, and use it somewhere else." Menu -> File should *always* contain "Save as..." so I can take what I've written and save it as a different version. (speaking of which -- when will Operating Systems start implementing integrated version control?)

For those of this generation who have used any version of a search engine well enough to know how to "manipulate" it (i.e., correctly use it) to find relevant results, we know that "-" (the minus sign) means "please, don't include this word in my search results".

I am not a frequent ebay user, but it delightfully participated in my "reality" by accepting that "-airsoft" as a search parameter meant I wasn't searching for an airsoft gun.

For better or for worse, users have already set standards for how our programs should function. To go against these "traditions" is to go against any other established societal standard -- to drive in the left lane; to turn a screw to the left in order to tighten it; to have the "power" button on the right-hand side of the TV remote-control; to defy gravity...

As any good citizen of the human population, our job is to question tradition; however, some traditions are so ingrained and so untouchable that we must acquiesce to the norms and toe the line.

When designing user interfaces, first ask yourself -- "would this be most natural to me?" As any HCI professor would tell you, that's not enough. You must think outside your own inclinations and actually consider the input of those who are not accustomed to thinking "behind the scenes" of an application -- who can actually (I might say "without bias") say "ladies and gentleman of the jury -- this. does. not. make. sense..

I wish that you would just leave
Because your presence still lingers here
And it won't leave me alone
These wounds won't seem to heal
This pain is just too real
There's just too much that time cannot erase
-- Evanescence - My Immortal

User Expectations

I put in my dollar bill, my quarter, my nickel, and my dime (notice that decreasing size dominates decreasing value). I pressed the "Mr. Pibb" button. And what happened?

Out came a Cherry Coke.

Strangely enough, I didn't really mind. I may not especially like Cherry Coke, but it suited me just fine: it had sugar and caffeine and that oh-so-great bitter-sweet cola taste.

My confusing experience at the vending machine is analogous to what users may feel while experiencing our applications. In my case, the supplier incorrectly loaded that particular slot; or, perhaps, loaded it correctly but didn't bother to change the label. Both cases pretty much sum up what we as coders are prone to do -- either not detect or not care about interface discrepancies.

Users can find these "mystery boxes" to be annoying, especially if they eclipse major functionality of the program. For instance, when no soda comes out at all after I've inserted my money and pressed a button -- well, I guess that's what Customer Service numbers are for...

What's bizarre to me is that I have heard of cases where a QA Engineer has discovered and fixed a "bug", only to cause Customer Service to become inundated with complaints regarding the missing "feature".

It shouldn't be so much of a stretch to imagine someone who uses who is used to pressing Mr. Pibb in order to get a Cherry Coke. But they've learned: either through their own mistakes or through someone else's -- that kind of knowledge is acquired, not explicit. Either way, money has been spent without total satisfaction.

Do you think that person would be annoyed if, unexpectedly and unannounced, a Mr. Pibb started coming out when they pressed Mr. Pibb?

Embrace your mistakes. Bugs *can* be features. If you still feel that serving up ice-cold Mr. Pibb is worth your while, make sure that it is clearly labeled, fully stocked, and that those who came for Cherry Coke can still get Cherry Coke.

From this time, unchained
We're all looking at a different picture
Thru this new frame of mind
A thousand flowers could bloom
Move over, and give us some room
-- Portishead, Glory Box

Priests in the Religion of Technology

If I had a dime for every time someone asked me "So, what's your major?" and I replied "Computer Science" and they replied "Oh...", and switched subjects...

Now, believe me when I say that I know we are nothing special. We are simply more familiar with a subset of today's technologies. I repeat, we are nothing special. No, really, they hate us.

I laughed at, yet was so humbled by, It Ought To Be Simple's post I'm An Idiot... (And Other Lessions From The IT Department). It seems we have a reputation with our friends and co-workers -- and not the good kind.

Yet you can't help but feel that we are part of a religion centered around technology... That we are the physical 'hands' of some super-natural being (i.e., beyond many people's understanding or interest) that affects the daily lives of millions of people.

Though it seems that the electronic deity we represent will be around for some time longer, some people are not so glad about it. Maybe they just need to meditate with their crackberries or plug in their earbuds and take control of their environment.

We are building a religion
We are making a brand
We're the only ones to turn to
When your castles turn to sand
-- CAKE - Comfort Eagle

(btw, Asimov expressed technology as a religion back in the 50's in his Foundation Series. And to think -- they had just developed Fortran...)

Hobbies Are Work, Too

I have friends who are musicians. To me, that always seemed like the most awesome hobby slash career in the world. I was very surprised to hear that, though they love making music, sometimes it can feel like a chore -- specifically, getting started on a track. When you have the concept for a song in your head that's been brewing for a while, you don't want to go back and start from the beginning -- to go through the necessary process of transferring it all from your head to a 'physical' medium. You just want what's in your head to magically exist, and go from there.

If you're like me, you have a lot of ideas swimming around in your head. Yet even though you are excited and have so many great ideas for extention, you never seem to get started -- there's some sort of mental block keeping you from saying "let's roll".

The fact is, anything and everything is work; because nothing is free. But sometimes things are worth their price tag.

Whether you're making music or a website, your outlook on the project is expressed through your coding. We are, after all, priests in the religion of technology. As Khoi Vinh says in 37signals' Getting Real, It Shouldn't be a Chore:

Enthusiasm manifests itself readily of course, but indifference is equally indelible.

So be positive. Start your next project with gusto. Because it's all about your relationship with your medium.

When you write a book, you need to have more than an interesting story. You need to have a desire to tell the story. You need to be personally invested in some way. If you're going to live with something for two years, three years, the rest of your life, you need to care about it.
-- Malcolm Gladwell

WebDev Performance Tests -- Everybody Wins !

Dave Dash at Spindrop wrote an article about results of a PHP performance test: single versus double quotes. Which method to use is age-old discussion that has plagued PHP developers since they read their first tutorial.

Dave ran three different tests 2 million times each: double-quote concatenation ("test " . $i), double-quote inclusive ("test $i"), and single-quote Concatenation ('test ' . $i). The results were as follows:

double-quote concat:     2.898087978363
double-quote inclusive:  3.5480048656464
single-quote concat:     2.8503499031067

To put that into perspective, here are the average times for each individual operation:

double-quote concat:     0.000001449
double-quote inclusive:  0.000001774
single-quote concat:     0.000001425

Those of us with Computer Science degrees are infamous for our nitpicking of details that do not affect the "bottom line". A classic example is arguing over which sorting algorithm to use. Sometimes we get so excited about the power we wield at our fingertips that we forget to get any work done.

So here's to us web developers caring less about saving 3.49e-7 seconds per concatenation and more about implementing functionality on time.

As Jeff Atwood points out, every algorithm is fast for small n.

(btw, I still will be using single-quote concatenation for its speed.)

Today's lyrics complements of blink-182's All the Small Things:

Late night, come home
Work sucks, I know
She left me roses by the stairs
Surprise let me know she cares

What is Your Coding Muse?

How much do you love what you do? I've just read the Creating Passionate Users article Don't ask employees to be passionate about the company! and really appreciated what she calls the "4-question test" for determining if someone is passionate about their work:

- keeps up with trade/professional journals
- knows who the key people in the industry are
- would spend his own money, if necessary, for better tools
- if they were NOT doing this as their job, they would still do something related to it as a hobby

We've all some reason why we do what we do.

Works late nights when, "I'm just one-compile away from this awesome refactoring that's going to make this thing run 40% faster."

I'm not sure about that figure, or how it was derived, or what she's talking about, or who she's talking to -- but I know that feeling; and I greatly enjoy that feeling.

What inspires you?
What keeps you where you are?
What keeps you from where you are going?

Today's lyrics complements of Muse's Sing for Absolution:

Lips are turning blue
A kiss that can't renew
I only dream of you
My beautiful