Everything In Between

Simplicity is a challenging goal for virtually every task you (or I) may have. Why is it a goal at all? Successfully reducing the presentation of complicated tasks into simple components is a goal because it is typically a required part for the success of the task.

Possibly the best example of this phenomenon in action is Wikipedia, which hosts several different versions of its pages. The version everyone knows about is the supremely academic one, the one Wikipedia presents by default. Here’s an excerpt of one such page’s introduction, the Wikipedia entry for the Standard Model of particle physics.

The Standard Model of particle physics is a theory that describes three of the four known fundamental interactions between the elementary particles that make up all matter. It is a quantum field theory developed between 1970 and 1973 which is consistent with both quantum mechanics and special relativity. To date, almost all experimental tests of the three forces described by the Standard Model have agreed with its predictions. However, the Standard Model falls short of being a complete theory of fundamental interactions, primarily because of its lack of inclusion of gravity, the fourth known fundamental interaction, but also because of the large number of numerical parameters (such as masses and coupling constants) that must be put “by hand” into the theory (rather than being derived from first principles).

Contrast the above with this excerpt for the same page, the Standard Model of particle physics, taken from the simple English version of Wikipedia:

The Standard Model of physics is the best idea to say how fundamental forces and elementary particles work. It uses quantum mechanics and special relativity. In physics there are many different particles and forces, the Standard Model says that all particles and forces are only two different types: fermions and bosons.

Okay, now that’s a lot easier to understand. In this example, the simple English version is a lot shorter, and at first glance that might strike you as its major distinguishing factor. However, if you read closer, you’ll notice many things specific to the language that was used that serve to give the simple English version much more accessibility than the academic one. Some of these things include:

• Simpler, more familiar vocabulary. Instead of using surgically-precise words that may not be familiar to an uninformed reader, plainer words (and no less accuracy) are used to describe concepts.
• Dense sentences are broken up into smaller chunks. When accessibility or successful communication is the primary concern, longer sentences that deliver more information in one punch may be counter-productive. Instead, it’s often better to chop up larger concepts and deliver them in smaller-sized chunks that are easier to digest.
• Specifics are introduced one at a time, and defined at each instance. Possibly the most common error writers (especially technical writers) make is introducing lots of interdependent ideas at once or without proper prior context. Rather than work your way from a complicated idea to a simple conclusion, work instead from a simple foundation to a complicated idea, building vocabulary as you go (see point the first about vocabulary).

Of course, this is always easier said than done, and it is also why simplicity is intuitively understood by lots of people to be a hard thing to create. Presenting things simply is a challenge because it requires more knowledge than simply understanding the thing; it requires understanding the thing and understanding what pieces of the thing your audience does not (yet) understand. The value of simple lies in being able to fill those gaps.

This is already horribly old news, and by old I mean several days ago since that’s about as fast as it takes technology news to grow old, but Apple is releasing Mac OS X 10.5 “Leopard” at the end of this month. Apple is calling this release a “major upgrade,” and indeed Apple has rarely made its users wait so long between operating system releases as they have done between Tiger (Mac OS X 10.4) and Leopard. So, I’m already excited.

But then today I was glossing over Apple’s featured features list and I got even more excited. There are the usual, largely meaningless, fluff updates that are nice for Joe Schmo or his mother, but that power users simply don’t care about, like the new iChat support for animated buddy icons, but the list is also chock-full of really cool, really useful features.

What’s interesting is that a good deal of these features aren’t really new features at all. For instance, if you knew how to manipulate the NetInfo database on your Mac, you could already share any folder via Apple’s “Personal File Sharing” feature. (Here’s a Mac OS X Hints hint explaining how to do it.) In Leopard, however, Apple claims that this functionality is now integrated straight into a folder’s Get Info… window. If it works as smoothly as Apple claims, this is finally going to bring Mac OS X (client) into decent competition with Windows XP Professional in terms of GUI-level power-user features.

However, while all of these features are really cool, here’s a list of the ten geekiest features I will probably absolutely love, for one reason or another.

• Ruby on Rails, out of the box — The hot thing in web development right now is Ruby on Rails. Macs have already been the best personal desktop and web development platform because they have built-in support for the Apache web server and a host of other features, but now they will come with a ready-to-roll installation of Ruby on Rails, sporting Mongrel and (better yet) Capistrano! Specifically with the addition of Capistrano, which is terribly undersold as simply a Ruby on Rails deployment platform, these UNIX-y “toolbox” items are bound to make Macs that much more useful right out of the box.
• Safari’s full history search — As their recent public partnerships with Google have shown, Apple is very clearly invested in search technologies. Spotlight gets a huge number of improvements in Leopard, but none which I think are going to be more useful to more people than this one: spotlight searches on the full text of each web page in your visited history list. That’s just awesome. Also awesome: using spotlight as a calculator and as a dictionary, which also shows just how Google-like Apple is trying to be. (Google also lets you ask it arithmetic questions and a dictionary.)
• Wikipedia articles in Dictionary.app — I love Wikipedia because it’s one of the fastest ways to get (relatively) reliable information quickly. Now that Dictionary.app has built-in integration with Wikipedia, imagine the possibilities for getting that knowledge instant-gratification craving fixed. Apple has not yet announced this capability, but I can easily envision a scenario where all Cocoa text fields are instantly “wikified” (with text that matches Wikipedia articles highlighted) much in the same way that current Cocoa text fields allow you to right-click on a misspelled word and have it corrected by Dictionary.app.
• Application-based firewall — In classic Apple fashion, functionality that was previously available via third-party additions is now available from Apple itself. In this case, I have to wonder how well Apple’s updates to its firewall will obviate the need for Little Snitch, which is basically an application-based firewall, too, and a good one at that.
• Built-in guest log-in account — If you’re as paranoid about security as I am, you’ve already created a special, limited-access user on your system (called Guest or Visitor or whatever) and whenever friends are over, you tell them to use that account instead of your own. Now in Leopard, Apple has gone through the trouble of setting this up for us already. A small change that is going to have a big impact.
• Scriptable System Preferences & applications — With AppleScript, you can automate the things your computer does with scripts, as long as those things are “scriptable.” In previous versions of Mac OS X, huge gaping holes of what things shipped by Apple were scriptable existed, causing me (personally) some really annoying headaches. AppleScript GUI scripting helped me get around many of those roadblocks, but now it seems Apple is finally filling in some of the most notorious gaps in this functionality with scriptable System Preferences. Yay!
• Automator workflow variables — Automator brings the power of AppleScript I just mentioned to more people with a completely graphic programming environment. There is no need to open up a text document and write AppleScript code because Automator lets you create a script (called a Workflow in Automator jargon) using your mouse by dragging and dropping actions into the order you want them to be performed. It’s very slick, but until now it’s been very limited. With Leopard, Apple is beefing up Automator so that it includes things like variables, basic programmatic capability that was sorely lacking before. (Also majorly cool: a command-line utility to access Automator!)
• Finder.app’s path bar — Every serious Mac user knows that the Finder needs a lot of help. Now, it’s getting some. Something the Windows Explorer has had forever (as had every desktop environment for Linux, of course) is a visual cue to show you where in your filesystem tree a given folder is located when you are viewing said folder. Now the Finder gains this capability (though Apple’s description implies that it’s going to be off by default) with what Apple is calling a “Path Bar”. Finally!
• Cocoa and scripting bridges — Even though no one really seems to know about it, it has long been possible for languages other than AppleScript to do things like send Apple Events to Mac OS X applications. Specifically, Ruby and JavaScript, two of the most well-known web development languages in existence, can already do this with a single ScriptingAddition (OSAX). But now Apple is making this functionality a central feature and fully extending it to their Objective-C (and Cocoa) language and applications such as Xcode and Interface Builder. This means people like me will have a shallower learning curve before we’re able to create full-fledged, native Mac OS X applications. Now that’s exciting!
• Xcode 3 refactoring — This is something you kind of have to see to believe. I got the opportunity to see it demoed at Apple’s Leopard Tech Talks last year and I was really excited by it. With the new Xcode, Apple’s development IDE, you can do away with find-and-replace searches for things like renaming functions because Xcode understands what parts of your code are what structures and, when you tell it to “change the function named myFunction to myNewFunction,” it’ll only find-and-replace function names instead of every instance of the string “myFunction.” That’s pretty big, and if it were available for more languages, it’s almost enough to make me ditch vim.

So there you have it. Ten features you might not have already known about that are some of the most promising features I can see in Leopard. And I didn’t even get into Wide-Area Bonjour, which could make services like DynDNS or No-IP a thing of the past (and which I still want to learn more about), or the new Terminal application (finally with tabs!), or even the multiple user certificates for S/MIME encrypted email.

Note: One of the least known security features available on Mac OS X is also possibly one of the best, and the simplest. Evidently, all Intel-based Macs are shipped with the XD (aka. NX, aka. DEP) bit turned on—and thankfully there doesn’t seem to be any way for users to turn it off. However, this isn’t a silver bullet and if you want to learn why you should check out this excellent Anandtech article: A Bit About the NX Bit.

While this feature has been around for a long time, not many people are aware that you can publish blog posts straight from Google Docs to just about any blog of your choice, including Blogger, WordPress, and others. This is pretty awesome for many reasons, but most important for many people is the incredible rich text, WYSIWYG editor that Google Docs offers.

I’m tempted to give it a shot myself, for many reasons. I think using Google Docs to compose and edit my blog posts may make it easier to:

• keep copies of my blog posts somewhere other than my blog (just in case),
• work on my blog posts from anywhere with an Internet connection (and under the security of an HTTPS connection!),
• version-control all of my writing without changing my workflow the least bit,
• invite specific users to preview my drafts before they go live and even help me edit my posts so I can catch typos and grammatical errors,
• easily export my writings to a variety of formats, such as PDF or a ZIP file with the ease of a single menu,
• and of course, instantly take advantage of whatever wonderful things Google has in their pipeline.

Another blogger wrote an entire how to article showing tips for using Google Docs to blog that is quite a good read, as well.

I have the simplest personal email spam solution in the world. I use Apple’s Address Book and, in it, I keep all the email addresses I ever want to get mail from. In Apple’s Mail program, I simply tell it that email from an address in my address book is exempt from being treated as junk mail. Then I set up a Mail rule that says if the sender is not in my address book, the message should be moved to the Junk Mail folder.

Voila. This system is flawless. You will never be able to send me loads of spam that go anywhere but my spam box, and I hardly ever look in there.

Naturally, there is a caveat to using this technique, but I actually consider it to be an advantage. By necessity, this technique, keeps me pro-active about getting people’s contact information when I meet them (and want to talk again). If I don’t get that person’s email address, I’ll probably never see that person’s email unless I’m looking out for it. Nine times out of ten, however, that’s what I want to have happen anyway.

So this solves the problem of unwanted mail. However, what if I want to let people contact me that I don’t know ahead of time or have previous whitelisted? Well, in that case I rely on an out-of-band communication, such as an introduction from a friend, leaving a comment on my blog(s), or some other method such as an instant message to let me know that there is someone who wants to talk to me.

My contact information is so available (in so many places), and many IM services are now equipped with store-and-forward messaging that there really is no reason for email to be the first time I hear from someone. Even better, if I’m contacted over Google Talk (as an example), I automatically have an email address for that person.

Voila. Simplest. Spam. Filter. Ever.

In a previous post I wrote a small expect script to update a remote web server’s deployed code on a new commit to a Subversion repository using Expect and Subversion’s post-commit hooks. That first script was extraordinarily basic, so I’ve been wanting to add some sanity and error checking to it for a while. I finally got around to it today.

This improved version of the post-commit hook does the same thing as the last one (that is, it logs into your web server over SSH with the given user and password, and yes, I’m aware of the scariness of embedding a password in such a way, so you should really set up SSH to use public keys for authentication for this), except now it also produces useful output.

Here’s the same script as before, but improved:

#!/usr/bin/expect -f

#
# AUTHOR: Meitar Moscovitz 
# DATE  : Thu Jun 21 16:32:42 EDT 2007
#

set HOST my.web.server
set USER someuser
set PASS xxx

# the working copy we're going to update
set WC /path/to/working/copy

# the path to the svn executable on the remote web server
set SVNBIN /usr/local/bin/svn

# our network is slow, set a long timeout
set timeout 30

##### DO NOT EDIT PAST THIS LINE! #####

# POST-COMMIT HOOK
#
# The post-commit hook is invoked after a commit.  Subversion runs
# this hook by invoking a program (script, executable, binary, etc.)
# named 'post-commit' (this file) with the
# following ordered arguments:
#
#   [1] REPOS-PATH   (the path to this repository)
#   [2] REV          (the number of the revision just committed)
#
# Note that Subversion does not provide this program with an environment
# of any kind. That means this program lacks a current working directory,
# a home directory, a $PATH, and so on.

set REPOS [lindex $argv 0]
set REV [lindex $argv 1]

# Define error codes
set E_NO_SSH     1 ;# can't find a usable SSH on our system
set E_NO_CONNECT 2 ;# failure to connect to remote server (timed out)
set E_WRONG_PASS 3 ;# password provided does not work
set E_UNKNOWN   25 ;# unexpected failure

# find the SSH binary on our system
if {[file executable /usr/bin/ssh]} {
	set SSHBIN /usr/bin/ssh
} elseif {[file executable /usr/local/bin/ssh]} {
	set SSHBIN /usr/local/bin/ssh
} else {
	send_error "Can't find a usable SSH on this system.\n"
	exit $E_NO_SSH
}

spawn $SSHBIN $USER@$HOST $SVNBIN update $WC

expect {
    "continue connecting (yes/no)? " { send "yes\r"; exp_continue; }
    -nocase "password:" { send "$PASS\r"; }
    timeout {
        send_error "\nWe have timed out after $timeout seconds while trying to connect to $HOST!\n";
        exit $E_NO_CONNECT;
    }
}

expect {
	-nocase "password:" { ;# if we are asked for the password again, then we have provided the wrong password
		send_error "\nCan not log in to $HOST because the password provided for user $USER has been rejected.\n";
		exit $E_WRONG_PASS;
	}
	-re "revision (\[0-9]+)." {
		if {$REV == $expect_out(1,string)} {
			send_user "\nSuccessfully updated $WC on $HOST to revision $REV.\n"
		} else {
			send_user "\nUpdated repository to revision $expect_out(1,string), but svn reports that we are at revision number $REV.\n"
			send_error "CAUTION: Repository updated to revision $expect_out(1,string), but committed revision $REV.\n"
		}
	}
	default {
		send_error "An unexpected error has occured. The process at spawn ID $spawn_id has produced the following output:\n"
		send_error $expect_out(buffer)
		exit $E_UNKNOWN
	}
}

In one of my web development projects, it became important to keep the staging web server in sync with the latest code that myself and several other developers were working on. There are a number of ways to mirror files and directories across machines, rsync being one of the most widely known. However, in addition to simply mirroring the files across the two servers, we also needed a way to kick off the mirroring process that cleanly integrated with our development workflow. Subversion’s post-commit hook allowed us to do just that.

Still, however, the problem was not exactly straightforward. We needed to execute a svn update command on a server other than the server on which the Subversion repository was being hosted. Shell scripts are the obvious choice for command-line automation in UNIX, but they don’t deal with interactive commands very well. So instead of writing a shell script, I wrote an expect script.

This expect script is really basic. There’s a better one in a future post on this topic.

#!/usr/bin/expect -f

#
# This expect post-commit hook connects to staging-webserver
# and updates the working copy hosted there to the latest checked-in code.
# This means that whenever code is committed to the repository, the web site hosted
# will always be running the latest version of the code.
#
# AUTHOR: Meitar Moscovitz
#

# POST-COMMIT HOOK
#
# [...]
#

set REPOS [lindex $argv 0]
set REV [lindex $argv 1]
set HOST staging-webserver
# Use update-user to log in to staging-webserver
# to update the working copy, but this can probably be improved so as not
# to expose this user's password.
set USER update-user
set PASS update-user's-password

spawn /usr/bin/ssh $USER@$HOST svn update /path/to/web/site/directory
expect "continue connecting (yes/no)? "
send "yes\r"
expect "password: "
send "$PASS\r"
expect eof

There’s one really tricky bit to this script, which is the understanding that when Subversion runs the post-commit hook, no environment information is passed to this script. As a result, there is no home directory or path information set for this executable. This is why everything is defined using absolute paths. Also, because there is no home directory for update-user, the expect script will always be prompted by SSH to re-verify the server’s identity. So rather than just expecting “password: “, we always expect “continue connecting (yes/no)? ” and say yes, and then send our password.

Note, of course, that update-user should be a user with limited access to the system, yet enough so that he may update the working copy on the web server. I’m sure there is probably a more secure way of doing this as well, so any sort of feedback on securing this or scaling it would be welcome.

It strikes me as very, very interesting how, especially in the world of technology where everything is thought to be so regimented and precise, where a single typo can be the difference between compilation and error, that there is so much versatility in every step of the creative process. This is, of course, a result of the nature of the industry, that being a knowlege-based economy, but the observation still holds strength.

I’m beginning a new project at work where, for the first time, I’m working with a large team of developers, and not just integration developers but front-end developers like myself. Since I’m the new guy, I’m finding myself required to learn the teams established vocabulary and this is making me realize just how much of my own vocabulary I have developed myself without even realizing how large it’s grown.

It all comes down to how we organize our code and that, of course, depends very much on how we are used to thinking about things. On a team of people working together for a common goal, such implementation-specific details are much more central to the success of the project than when working alone, such as in a freelance situation.

It’s interesting to me to see how many of the the established coding standards and naming conventions are obviously built off of the same kinds of ideas that I’ve already had and have been using for quite some time, and yet how different they are in implementation. This extends beyond the obvious case of using dash-separated class and ID names instead of camel case lettering or vice versa. It goes so far as to project management and workflow considerations, file name conventions, and semantics.

In some cases, optimizations are actually sacrificed on a team in favor of clarity, but this is actually a good thing. In my freelance work, I typically squeeze every last ounce of optimization into a project by using shorter names, more optimized files, and extremely dense code to ensure the best possible result. In a project with other developers however, the success of the project is far more dependant on everyone’s collective understanding of the code, so clarity is and should be prioritized above optimizations.

Define success. Success means growing, making things easier, doing more in less time, etc. There are entire industry movements dedicated to figuring out how to be the best at being successful. Heck, there are even acronyms (imagine that!) for it in all sorts of speech domains, such as in business, where ROI (Return on Investment) is huge, and in productivity, GTD (Getting Things Done) is a huge fad right now. What I think people often misunderstand or fail to realize is the very simple fact that success is much harder on a large scale than on a small one. Why is this the case?

Well, obviously, success on a large scale means accomplish “much more” than success on a small scale. Also, success on a large scale often means working with more than one person where collaboration is a must. So what are the tools people use to accomplish this success?

The most well-known tool is management. Implement a structure in an organization that is overseen by people whose job it is to make sure success happens on varying levels of scale. The larger an organization gets the more managers it needs, not because of personnel (technology advancements and process improvements in Human Resources have significantly the amount of employees a company can keep track of) but rather to ensure that this army of personnel is not going to lose sight of whatever is deemed the successful goal in their appropriate “big picture.” For CEOs, this means the company’s bottom line. For regional managers, this means their region’s bottom line. For individual supervisors, this means success completion of the task their division was handed, and so on and so forth.

Clearly, this is an important and necessary part of doing business. But I theorize that businesses and large organizations tend to see the act of adding more management to their organization as an act of ensuring a return on their investments which is probably overestimated. A manager is someone you have to pay (often a lot more than other forms of employees), and whose job actually adds to the complexity and opaqueness and beurocracy of an organization. At some point, this must be more harmful than helpful.

So what else can be done? I would suggest that an often very underestimated and underutilized area of increasing ROI is by improving knowledge transfer and knowledge sharing between employees. Why? Because it builds on the concepts and proven methodologies of small-scale success wherein many small successes brings larger success naturally, rather than forcefully. I see the largest contributor to small-scale success (most explicitly evident in personal successes, probably the smallest scale you can get) as the increase of knowledge. My own experience has taught me that I am more productive now than I was one year ago because I can do more than I could do one year ago, and I can do more now than I could then because I know more about the world and the objects within it.

Applying this to a larger scale is simple in theory but difficult in practice. In theory, the more smart people an organization has working for it, the more collective knowledge is stored within that organization. In practice, this is actually a huge problem that the solution called management is attempting to alleviate because smart people tend to be very insular and self-driven. This leads to a phenomenon I have begun calling knowledge fracturing which ultimately results in siloed and specialized skill sets with little ability to expand beyond that specialization. This is so significant a problem in large organizations that entire industries and bodies of knowledge have been created to help alleviate workflow problems and help facilitate communication.

Now, this is good, because a prerequisite to knowledge sharing is communication. You can’t share what you know if you can’t communicate with someone who can listen. But this is only the first step. Certainly, an organization can ensure better ROI with communication tools, but the next level–which I have yet to see anyone focus on too obviously–is knowledge sharing; communication with the intent of making available the information one has accumulated to the point that enables one to share the information about one’s job function or skill set.

This is a concept that is actually extremely scary to most people. There are two oft-cited rebuttals to this. The first involves a concern for job security. If everything that I know about how to do my job and why is written down for fellow employees to see, what need is there for me? I maintain that this actually makes you as an employee more valuable, rather than less, because suddenly you are a teacher, a reference guide, an invaluable “go-to guy.” The more you share, the more clearly people understand what you know and what you’re good at. Sharing, at its roots, is all just about showcasing what you’re good at. How can that be bad?

The second involves a concern for an organizations information security, wherein too much knowledge sharing can actually be security breaches and information leaks that are unacceptable to the organization’s policies. Obviously, while this is an important issue, it is not a direct argument against the validity of knowledge sharing but rather an objection to a side-effect of it if it is done carelessly. As with all things, I think most people will agree that care should always be taken in everything you do. This is just one more example.

So why does knowledge sharing actually increase the overall ROI of an organization? I theorize, based solely on my own experiences, that the majority of time and expense that is not directly spent on progressing an organization’s goals are spent trying to navigate a system or accomplish a task that is only difficult because it is not understood. If it were understood, the procedure would take less time, or the company would not need to hire a consultant, or whatever the situation may be. The point is that if you know what you’re doing, you’ll do it more effectively and more efficiently.

Successful knowledge sharing increases the productivity, effectiveness, and efficiency of your organization by enabling your staff to accomplish orders-of-magnitude more than they would otherwise have been able to.

With that as a foundation, let’s next explore how an organization might go about successfully sharing knowledge. And as you may have guessed, I have one word that: wiki.

(I have not yet written the next part.)

Since I began my new job, work has been an interesting rollercoaster of extremes. I keep wavering between feeling anxious and feeling bored, the two opposing sides on either side of the flow channel. This is rather frustrating. Half the time I’m not being productive because I am trying to make sense of something I very obviously don’t understand and don’t have any reliable resources from which to learn about the thing, and the other half of the time I’m not entirely sure if I what I’m doing is correct because it seems like such a little amount of work (because it’s easy to do).

That said, I have been learning a lot lately. I’ve gotten to put my hands on software I’d never have otherwise gotten to touch (like Solaris 9 and Red Hat Enterprise Linux), I’ve learned more about Subversion and how to use it than I thought I would have in the little time I’ve used it, and my practical networking knowledge with regards to things like VPN routing have been substantially increased. Even more interesting than all of this new technical skill, however, is all that I’ve experienced on a cultural level.

I am now certain that what I am experiencing is intense culture shock. Let me explain.

The first thing people notice when you move to another country is probably the way people speak. Specifically, the two things people most often comment on is the language being spoken, and how it sounds (accent, common sounds, etc.). Similarly, the first thing I noticed when I got hired was the way people spoke, and what they were saying. The heavy use of acronyms are not new to me, but at the amount of company-specific technical jargon is hard to decipher when there is no Wikipedia to search. And farbeit for there to be a single, updated glossary that is easy to reference, either, or have someone offer to expand an acronym without you asking for them to do so.

Even more bewildering than the array of new acronyms, however, was the use of what I have come to call businessese. This is a language whose apparent sole purpose is to make whatever you are saying sound very important and hard to accomplish. An example would help clarify this.

The other day I was asked to review a written document. It was written by a colleague of mine. Our mutual boss, probably wanting me to get familiar with the look and feel of the documentation, sent it to me and said something like this in an email:

Meitar, here is [document X]. Please ensure it is ready for delivery to the client.

What he actually meant was something like this:

Meitar, here is [document X]. Please proofread this for any errors and then let us know so we can pass it along to the client.

My lesson from this experience, and from numerous similar experiences lately, is that people in the corporate business world don’t tend to actually say in plain English what they want you to do.

Another interesting point of fact I’ve encountered lately is the incredible difference it makes in the technical arena when you communicate with precision. This is difficult to do, because there is often an unacceptable latency if you speak with too much precision. This is why acronyms are so useful, if you know what they mean. In other words, if you already know what a web browser is, there’s no need for me to specifically name your web browser when I tell you to go to a particular web page. But if you didn’t know what a web browser was, then I would more likely get my message successfully delivered to you if I told you to type a certain string into the address bar of a particular program, say Firefox, instead of saying “go to this web address in your browser.”

This is also nothing new to me, but this week I am working with two colleagues who are utter opposites of each other in this respect. One colleague, whom I’ll call Descriptive, speaks slowly and clearly when he talks and assumes just enough technical familiarity with the subject to speak somewhat concisely, without sounding condescending. He is also quick to offer expansions for acronyms or further explanations of specific sequences of actions when he senses they are needed, as well as omitting them when he notices the listener is loosing focus. It’s very obviously a skill.

The other colleague, whom I’ll call Snappy, speaks so quickly I can’t tell when he’s taking a breath (if at all). He absolutely never expands acronyms, nor does he provide any sort of context for what he’s saying, such as a window’s title or an a filesystem location. He reminds me more of the character Nick Burns from the SNL skits of “Your Company’s Computer Guy” than anything else. I don’t doubt his technical ability at all (he’s very obviously quite skilled), but after mere days, I find myself dreading the prospect of working with him in the future.

There are thus two ultimate conclusions I can draw from these obervations (at least right now). Since I know that I am far too much in love with precision and clarity (and usability) to tolerate any confusing imperfections in what I create, I have the potential to become very well-liked for my helpful nature if I learn enough that I can actually answer questions when they arise. This bodes well for me.

Concerning, however, is the possibility that all this businessese nonsense will ultimately get to me. I truly, truly despise it and try hard not to cringe whenever it rears its head. I can’t understand for the life of me why my bosses don’t talk like humans nor can I understand why the majority of amazingly bright people (many of whom are more technically adept than myself) can’t be bothered to make the slightest effort to think more than one or two steps ahead of themselves. There are, of course, exceptions, but the fact remains that these are exceptions and not the rule.

I am notorious for conjuring up utopian visions in my head and then not settling for anything less. Here we go again.

Tomorrow, I begin my first day of official employment with Opsware, Inc., a relatively small company whose focus is various solutions to the challenges of data center automation. This is a very exciting new challenge for me, personally and professionally, and I’m thrilled for the opportunity. Naturally, however, this means my focus will (probably) shift away from projects such as those that I was doing under the Maymay Media umbrella in order to devote more time to Opsware. Of course, it also means that I have officially resigned from my position at Apple Computer, Inc.

The whirlwind of events that lead to this new job have been the most compelling evidence I have ever encountered strengthening my arguments for the importance of relevancy. Throughout all my experiences, I have consistently been given sage-sounding advice: “Be patient. Put your time in now, and that will happen.” I’m sure you’ve been told the same thing countless times, in different contexts applicable to whatever situation you were in.

This statement, when taken literally, is in fact rather wise. Essentially, the advice is reminding you to choose your battles, and that’s a very smart (and mature) thing to do. However, most people hear two very distinct things when given this advice which can be paraphrased thusly:

1. Wait.
2. Compromise your goals.

Worse, some people actually mean these things. I will agree that the first point is indeed sage advice because it is unavoidable. I will forever continue to disagree with the second because doing so is nothing but a waste of time.

I first remember being given this advice in second grade, when I remarked that I disliked my teachers. Be patient, I was told, it would surely get better. And if it didn’t, well, next year will be different. Next year was different, but I was equally displeased with the school. Don’t worry, I was told, just put in your time at school and eventually it’ll pay off.

But that’s a lie. Putting your time into something never pays off, ever. Doing things pays off. So if you’re putting your time into something doing something you can’t see paying off, why continue to do it? That was the crux of my argument against my traditional schooling (which I eventually broke free of at 16) and was also the motivation for taking this new job opportunity.

I am notorious for being impatient. I rarely argue this fact with anyone because, by all measure, I truthfully am impatient by the standards of those who declare me to be impatient. However, all I see is a difference in priority. I am far more interested in the timeframe necessary to achieve my desired results and I am also aware of many possible paths to take to obtain said results. Many of these paths take a lot longer than others. When confronted with a choice of which path to take, I weigh my options and ask myself why I would take a longer path?

Is there some benefit to the longer path than the shorter one? Would the longer one yield a higher quality result? Is there some cost to the shorter path? Would the shorter one require too many resources, more than I can afford? Most people never get to see other people making these choices. They only see the actions one takes, and that can be misleading.

Yes, learning to take the good with the bad is an important and valuable skill. Yet I insist on reminding people that it is a fine line between that and taking the bad for the good. I would never allow myself to do that, to compromise my goals, their quality, or their timeframe, for something that just isn’t worth it. For me, one of those things that just wasn’t worth it was schooling. A more recent example of something that just wasn’t worth it was the slowness with which advancement from within Apple Computer could move my career forward and become more in line with my passions.

I’m excited, if slightly nervous, about starting with Opsware. I think (and hope) that one of the reasons I was hired was because of the very attitude I expressed during this post. If so, then I’m sure I’ll have a fantastic time and be a great asset at the same time.

Don’t expect to see too much about Opsware here. I don’t write about work-related things very often, if at all, but I sure hope that my experiences there will provide much fodder for more material in the future. And in other news, I took and passed the CompTIA Security+ certification test (the day after my Security+ prep guide came in the mail, go figure).