Program Like a Pixar Story Artist

A friend recently tweeted a list of story basics from Pixar Story Artist Emma Coats. These basics are some of the story-writing guidelines Emma has learned from her colleagues and they’re pure gold for writers.

As I was reading the list I was struck by just how many of the items on her list–with just a little modification–apply to programming as well. It’s all creative work. It’s all writing.

Story Code
#2: You gotta keep in mind what’s interesting to you as an audience, not what’s fun to do as a writer. They can be v. different. You gotta keep in mind what’s interesting to you as a user, not what’s fun to do as a coder. They can be very different.
#4: Once upon a time there was ___. Every day, ___. One day ___. Because of that, ___. Because of that, ___. Until finally ___. In order to ___ as a ___ I want to ___. Given ___ when ___ then ___.
#5: Simplify. Focus. Combine characters. Hop over detours. You’ll feel like you’re losing valuable stuff but it sets you free. Simplify. Focus. DRY it up. Hop over detours. You’ll feel like you’re losing valuable stuff but it sets you free.
#6: What is your character good at, comfortable with? Throw the polar opposite at them. Challenge them. How do they deal? What are you good at, comfortable with? Throw yourself at the polar opposite. Challenge yourself. How do you deal?
#7: Come up with your ending before you figure out your middle. Seriously. Endings are hard, get yours working up front. Come up with your test before you figure out your method. Seriously. Passing tests are hard, get yours working up front.
#8: Finish your story, let go even if it’s not perfect. In an ideal world you have both, but move on. Do better next time. Ship your code, let go even if it’s not perfect. In an ideal world you have both, but move on. Do better next time.
#10: Pull apart the stories you like. What you like in them is a part of you; you’ve got to recognize it before you can use it. Pull apart the code you like. What you like in it is valuable; you’ve got to recognize it before you can use it.
#11: Putting it on paper lets you start fixing it. If it stays in your head, a perfect idea, you’ll never share it with anyone. Put it ‘on paper’ lets you start fixing it. If it stays in your head, a perfect idea, you’ll never share it with anyone.
#13: Give your characters opinions. Passive/malleable might seem likable to you as you write, but it’s poison to the audience. Be careful with your users’ options. Abundant options may seem good to you as you code, but it’s poison to the product usability.
#16: What are the stakes? Give us reason to root for the character. What happens if they don’t succeed? Stack the odds against. What are the stakes? Know the reason for the feature. What happens if it doesn’t work? Handle this gracefully.
#17: No work is ever wasted. If it’s not working, let go and move on – it’ll come back around to be useful later. No work is ever wasted. If it’s not working, let go and move on – it’ll come back around to be useful later.
#18: You have to know yourself: the difference between doing your best & fussing. Story is testing, not refining. You have to know yourself: the difference between doing your best and fussing. Coding is iterative.
#19: Coincidences to get characters into trouble are great; coincidences to get them out of it are cheating. A hack to get the test to pass is great; a hack which ends up in production is cheating.
#20: Exercise: take the building blocks of a movie you dislike. How d’you rearrange them into what you DO like? Exercise: take the building blocks of some code you dislike. How would you rearrange them into what you DO like?
#21: You gotta identify with your situation/characters, can’t just write ‘cool’. What would make YOU act that way? You gotta identify with your users; you can’t just code ‘cool’. What would make YOU use this feature?
#22: What’s the essence of your story? Most economical telling of it? If you know that, you can build out from there. What’s the essence of your feature? Most economical coding of it? If you know that, you can build out from there.

Look at the world around you and what people in other fields are doing and you’ll be amazed at the lessons they can teach you.

Open Source: Why Can’t We Just Make It Easy On New Contributors?

As an Open Source advocate I’m frequently asked to which projects I contribute. My answer is typically, “None right now.” Why is that? There are a few reasons but they mostly boil down to:

  • As someone who does not code often (or enjoy it immensely) I do not feel welcome.
  • It’s an opaque process.

For now I’ll set aside the first reason to focus on the second: the process is opaque.

From my point of view, there is absolutely no excuse for this. Wikis, CMSs and cheap hosting all make it abundantly simple to offer plentiful guidance to new contributors, yet somehow that guidance is rarely provided. New contributors must delve and divine and guess and pester in order to figure out where to start. It’s almost as though the community does this intentionally as a sort of rite of passage for new members. “If you can figure this out then you’re smart enough to become One Of Us.” This is incredibly arrogant and exclusionist.

Why can’t we just make it easy on people? Why can’t we spend a few hours writing some documentation and tutorials up front, guiding newbies along the community-accepted path of contribution? Long time contributors may find the concept of spoon-feeding new members offensive but doing so will not only bring in more people to the fold it will also raise the quality of the contributions from the get-go.

To demonstrate how a project can make it easier for new contributors I’m going to use the Perl project. This is not because it’s such a bad example of how to do things (it’s pretty good, really) but because I’m fond of Perl and want to make some suggestions on how to make it even better. Also, I know that the Perl community is generally friendly and open to ideas on improving community involvement. That said, most of the suggestions are more generally applicable to all Open Source projects.

First of all, kudos to Perl for having a dedicated Get Involved link very prominently displayed there at the top of every page of Perl.org! This visibility is a testament to the importance of contributions and contributors to the Perl community. Involvement is key for them and they put it front and center, right where it deserves to be.

However after that things get less obvious. The site is clean and well-designed, which is a pleasant change from many project pages, but this page is essentially just a list of bullet points with no context or meaning. For instance, what would I as a new contributor be expected to do with the Bugs, testing and reviews section? Is this for reporting bugs (yes) or fixing them (not so much) or…? What is meant by “testing?” Since I pay attention to happenings in the Perl community I know that this means automatically reporting test results to the imminently cool and useful CPAN Testers when I install new CPAN modules, but what if I were entirely new to the Perl world? I may think that “testing” implies a lot more hands-on work, perhaps testing new commits to the core language. It’s not obvious and it really should be.

The tagline of this page is Whatever your skill set or level you can get involved… While I believe this must be true, speaking as a mostly-non-coder this page does not make it obvious how I could get involved with the Perl project. Are there simple bugs I could fix (and if so, how)? Maybe documentation that needs writing/editing? How about project management? Ticket review? Marketing? Event organization? Donations? Not only are these subjects a good way to capture the less technical users and supporters of your project, they’re also a brilliant way for the new coding contributors to get a feel for the project and up to speed on the processes it uses.

Here’s a quick and dirty first draft of a version of this page which would be more useful to new contributors:

Whatever your skill set or level you can get involved…

Community

Some say CPAN is the strength and heart of Perl, but they’re wrong. The people are the heart of Perl.

Getting Started

Ready to dive in? Here’s how to do it!

Everyone
  • Contributor FAQ Every project has those questions which come up repeatedly. Collect them and their answers to help remove the barrier to entry.
  • An overview of the processes used for Perl. Link to another page. Key for everyone to know the steps in the process, not only so they’ll know what to expect but also so they’ll know better what language to use when asking for help.
  • Where to go for help. While this should be an element of every bullet point here, it also should be aggregated on a single page for ease of use. Broken down by subject. Include names whenever possible (mentors would be awesome and heroic). New contributors are more likely to ask for help if it’s obvious there’s a real person at the other end.
  • Where to find the documentation. Link to another page. List every form of docs that exist. Keeping all this in one place drastically reduces frustration for new contributors.
  • Where to find the code. Link to another page. Not just where to find it, but how to get a copy and, if you wish to commit, how you’d go about doing that (including expected code style).
Non-Coding
  • Review and rate – the CPAN modules you use.
  • Send automatic reports to CPAN testers every time you install a new module.
  • Review trouble tickets. Link to a page describing the process, requirements and expectations for reviewing project trouble tickets. Ideally will include a link to a list of tickets in need of review.
  • Write or edit documentation. Link to a page describing the process, requirements and expectations for writing or editing project documentation. Ideally will include a link to a list of documentation tickets.
  • Translate documentation. Link to a page describing the process, requirements and expectations for translating project documentation. Ideally will include a link to a list of translation tickets.
  • Organize or Volunteer at an event. Calendar/list of events (locations and dates), assistance required and whom to contact for more information.
  • Donate. Link to a donation page and/or page detailing whom to contact to give a donation.
  • Have another idea how you could help? Contact us! Link to the correct contact information.
CPAN
  • Best Practices for coding for CPAN.
  • How to report a bug for a CPAN module.
  • How to contribute a fix for a CPAN module.
  • How to contribute a new CPAN module.
  • Contacting CPAN module maintainers and what to do if they don’t respond.
Core

Perl6

Want to learn more about Perl6? Have a look over here! Anticipate the question rather than forcing it to be asked or searched for.

Again, this is just a quick pass at a possible Contributors page, but as a non-contributor it’s much more inviting than the current, sparse version. I can easily look at this and see my options and the methods for performing them.

Granted, there is a lot of organization and writing which would need to be done for a page like this to work. Believe me, I know it’s not easy getting all these ducks in a row. That said, I strongly believe that any project which goes through the steps necessary to make it much easier for new contributors to join will find its quality and reputation improving by leaps and bounds. It’s an effort very much worth making.

Staff Quality Deserves the Same Care as Software Quality

The Wikipedia definition of Continuous Integration (aka CI):

Continuous Integration aims to improve the quality of software…by replacing the traditional practice of applying quality control after completing all development.

The CI gurus in the audience will hopefully forgive me for criminally over-simplifying, but the process basically boils down to:

  • Commit early, commit often.
  • Automate tests, build and deployment.
  • You break it? You fix it. RIGHT NOW.

The key motivator in CI is right there in the definition: quality. Rather than waiting for the end of the production cycle to do all of the testing you do it in smaller increments throughout the project. The sooner you locate and correct potential issues the higher the quality of the finished product. This approach is proven for developing software, so why aren’t we also doing it when developing staff?

A typical methodology for managing professional development for a technical staff member is much more old school waterfall in nature:

Yearly review and feedback
  set yearly goals
    procrastination until just before next yearly review
      race to complete goals
        verification of goals in yearly review
repeat

OK, perhaps that was a somewhat snarky summary but I think we all recognize it as Standard Operating Procedure. How, really, does this process help anyone? No, don’t answer that; I’ll answer it for you: IT DOESN’T. By the time you get to the annual review, any sort of feedback is so much water under the bridge and far from actionable. Yearly professional development goals are reduced to the effectiveness of an open book midterm: crammed in at the last moment and generating a good grade but with no lasting value, either for employee, team or company.

Instead we should be approaching staff development and management with an approach incorporating the ideas of accepted software development methods like Agile and Continuous Integration:

  • Agile Professional Development:
    • Employee review cycles should be short sprints of a matter of weeks rather than months.
    • Professional development goals should be attainable and meaningful, each subsequent goal building upon the ones which came before.
    • Meetings for checking progress and providing feedback should be frequent, brief and informal. They also should be open, honest and egalitarian (managers need feedback as much as anyone).
  • Continuous Staff Integration:
    • New knowledge and skills gained through professional development should be committed back to the trunk (the team) for integration.
    • Staff development should be automated through empowerment, support, policy and culture rather than dictated by managerial fiat.
    • Notification of potential issues should be immediate and methods of correction should ideally be evident and obvious.

There are, of course, some potential drawbacks in rolling out a staff development process of this sort. The current “waterfall” model has been the standard for a great many years and has become ingrained in the operating manuals for many companies, affecting the ways budgets are written, compensation packages are structured, Human Resources offices are run, etc. It’s difficult to overcome this sort of institutional momentum.

In addition, this process has the potential to impose a hefty burden on tech managerial staff. The impact of yearly reviews for each staff member can be severe enough on a manager’s time. Without proper planning an agile and continuously integrated professional development method could become a fulltime job in its own right.

These drawbacks are not inconsiderable but they’re also solvable and worth the time to do so. It will take a lot of planning to be sure this process is rolled out in a way which makes the most sense for your organization, but as with any worthwhile change (say, to using Agile and a rapid release cycle), if done mindfully the benefits reaped more than repay the effort.

Rant: I Am Not a Cat Herder

Cat Herding image CC-BY courtesy of carterse on Flickr; click to view originalIt’s a no-brainer. It’ll happen. If I were the betting kind I’d lay good money on it. Any time I’m mingling at some social event (cocktail party, BBQ, conference hallway track or pub outing, etc.) there will be at least one conversation which proceeds thusly:

Them: So, what do you do?
Me: Oh, I’m a software engineering manager.
Them: Ah! You herd cats! <insert self-satisfied chuckle at their oh-so-original witticism>

My typical response is to grit my teeth, smile wanly and change the subject. But ya know what? I don’t think I’m going to do that anymore. I’m rather fed up with the all-too-common misconception that managing software engineers is as chaotic and fruitless as wrangling a passel of felines. Seriously, if you’re a dev manager who describes his/her job as “Cat Herder” then just get the hell out of the business now. You don’t respect your staff and you’ve entirely missed the point of your job.

At no point in the management process should there be anything resembling “herding.” If your team requires herding then the problem is not the typically independent and outspoken nature of the software developers that comprise it. The problem is you. You don’t know how to be a manager. Communication, negotiation, mentoring, prioritization, leadership… These are the skills of a successful dev manager. Failure to learn, employ and constantly improve these skills leads to a team full of cats, loose cannons, powder kegs, prima donnas…choose your favorite negative descriptor.

It’s possible to learn these skills but only if you realize that it’s necessary. A good first step toward that is to stop implying your staff are unmanageable by calling them cats. Respect them as the intelligent people that they are, listen to what they have to say and clearly communicate the direction the company needs them to go and why. You’ll find that what you end up with looks a lot more like a functional and efficient team than cantankerous felines.

Book Review: “The Information Diet” by Clay Johnson from O’Reilly Media

Book cover for The Information Diet

“Much as a poor diet gives us a variety of diseases, poor information diets give us new forms of ignorance—ignorance that comes not from a lack of information, but from overconsumption of it, and sicknesses and delusions that don’t affect the underinformed but the hyperinformed and the well educated.”

This is the general thesis of The Information Diet, a new book by Clay A. Johnson, published by O’Reilly Media. In it Johnson explores the state of information production and consumption in our society, how he perceives it has changed (for the worse), the cultural, emotional and neurological reasons why this is the case, what may happen if the pattern continues unabated, and how we can work to reverse the trend.

The analogy of information as food is maintained throughout the work. I knew this going into it and anticipated the comparison would wear thin rather quickly. Aside from being personally bored by the first chapter—which summarizes the history of food industrialization and the obesity epidemic, subjects into which I’ve delved for years—the analogy works surprisingly well for the entirety of the book. Through this strong parallel to such a well-covered and -publicized public health issue Johnson is able to engage the attention and sympathies of the reader more or less immediately.

Unlike many of the more conventional “diet” books on the market, The Information Diet does not spend most of its pages on a detailed plan you could follow to reduce your intake of junk information. Johnson does, of course, give some tips on how to do this, but most of them are summed up in his Pollan-esque statement of “Consume deliberately. Take in information over affirmation.” Instead, the majority of the book is concerned with the dangers of our current information diets. It is, to maintain the food metaphor, more manifesto than menu. Those of you who read the title then pick up this book hoping to see detailed steps to achieve Inbox Zero may be disappointed on that front. However, if you’re looking for motivation to make a more fundamental shift in your attitude toward information intake you may have come to the right place.

I am myself someone who already keeps her inbox hovering at or just above zero, who regularly scrubs her RSS subscriptions of feeds which were added more for whim than value and who filters her Twitter and Google+ to raise the signal to noise ratio. In this way I’m not really the appropriate audience for this book. I am the choir to Johnson’s preacher.

However there’s a stronger reason why I am not the audience for this book: I am neither political nor activist. The final chapter of the book is pure manifesto, enlisting reader assistance in using their newly-reformed information diets to effect governmental and political change. Considering the author’s background his concern with changing government is no surprise, however I admit that I was as turned off by it as I am by most other forms of activist outreach (political or otherwise). This isn’t Johnson’s fault. It’s my own hang up.

To be entirely clear: this is a good book. It’s well-researched, well-written and covers topics with which I believe more people should be familiar. It’s a good book, just not good for me personally. I recommend that anyone with an interest in any form of information consumption pick up a copy and make up their own minds.

Disclaimer: I received my copy of this book for free via the O’Reilly Blogger Review Program.

Technical Job Postings: Know Your Audience

Spotted in a job posting for a technical position:

$Company is a values-based, social change platform that leverages individual and institutional leadership and investment to positively impact local and global communities. $Company pursues multiple, related strategies to promote this mission. From green nonprofit centers to programmatic consulting, donor advised funds to fiscal sponsorship, grants management to risk management and more, $Company gives members of the nonprofit and philanthropic community freedom to focus on the change it wants to see. For more information, please visit www.domain.tld.

A panel from Gary Larson's Far Side comic: What dogs hear blah blah blahI don’t know about you, but my eyes slid right off that description right around the word “leverages.” After investigating $Company more I can see that it’s a very respectable organization with a long history of assisting non-profits, both organizationally and financially. And, yes, if you take the time to play through the buzzword bingo in their description, it does actually tell you that. So…uh…why couldn’t they just tell us that?

When writing up a technical job posting (or any job posting, for that matter), keep your audience in mind. You are going to get better responses to a posting which uses clear, direct language than one which reads like it was written by a marketing intern looking to impress. Frankly, this sort of thing just scares technical people away. They read it and think, “Wow…is the entirety of $Company that stuffy and corporate? Is it one of those places where everyone wears suits and Casual Friday means a polo shirt instead of button-down? No flip-flops? Hrm… There are postings for other companies which sound more my style. I’ll put my effort into applying for those instead.”

In this case, I’d rewrite the description above to make it more casual:

Since $year, $Company has been helping non-profits with organization, logistics and finances, freeing them up to be the change they want to see in the world. There are $number non-profits of all sizes using our tools, including $np1, $np2, and $np3. We’re looking for a socially-minded $position to join our team.

That’s just a first pass and undoubtedly isn’t the best description possible but I’ll wager you a pint of good beer that you read it and found it more appealing than the original. Aside from improving on the stuffy tone, this version accomplishes a few things the first doesn’t:

  • Tells you up front how long $Company has been around, establishing credibility and stability.
  • As a programmer you now know that there are tools to be built. This gives you an idea of what you’d probably be working on. Also, who doesn’t like good tools?
  • Gives you an idea of the extent and nature of the clientele of $Company, helping establish $Company’s identity and philosophies. For instance, if $np1, $np2, and $np3 are all institutions with which you strongly agree then you can be more confident in fitting in at $Company, which is willing to be publicly identified with these institutions.
  • States outright that they’re looking for socially-minded people. If you’re just looking for a paycheck you probably should look elsewhere.

Bottom Line: Never forget that when you write one of these things you’re advertising that job position. Take the same care in audience discovery and wording as you would with any other marketing outreach. Be honest, be direct and use the language your audience expects to hear.

Book Review: “Process Improvement Essentials” by James R. Persse, PhD

tl;dr: A well-written book I’d recommend to all in the IT field who have any interest in working smarter rather than harder to bring their projects in on time, on budget and to customer spec.

Cover of Process Improvement EssentialsProcess Improvement Essentials, written by James R. Persse, PhD, delivers on its title. The field of process improvement is large, detailed and complicated—much more so than I would have expected before reading this book—yet Persse manages to curate, condense and present the topic in a highly effective and approachable manner. Which, I suppose, is to be expected considering the subject matter in question.

One method Persse uses to curate and condense is by limiting his target audience to IT professionals. The entire book is presented from the point of view of improving the quality of IT deliverables in whatever form they may take so, as a techie yourself, you can pick up this book without fear of getting mired in descriptions of processes (billing, accounting, manufacturing, marketing, sales, etc.) in which you may have little direct interest.

The book itself is organized into two sections. The first discusses process improvement in a more general sense and was the part of the book which I most enjoyed. The philosophies of process improvement resonated well with me, however that’s no surprise as I’m already predisposed toward the concept. Persse’s writing is clear, engaging and filled with quotes which struck me enough to write them down. Some examples:

From my experience, technology industries—corporate software, systems development, and operations—have been somewhat immune from the cleansing light of public failure.

Companies that are doing well are rarely motivated to initiate process improvement programs or quality initiatives.

…everything we do should be somehow traceable to satisfying the customer.

After all, if you hire competent people, you should probably get out of their way and let them do their jobs.

The second section of the book is a fairly in-depth overview of three process improvement methodologies: ISO 9000, CMMI, and Six Sigma. While moderately interesting, I recommend initially only skimming this half of the book then returning to it more in depth when/if your team decides to undertake one of the methods detailed here. This half of the book will be valuable both in aiding selection of the best method for your team as well as for basic reference while implementing it.

In a profession fraught with projects which are over budget, overdue or outright canceled more often than they’re successfully concluded, I would recommend that every IT professional pick up and read a copy of this book at least once in their career. Even if they only read the first half, the raised awareness of quality and process can only help improve the overall IT project success record.

At Risk: An Online Service is Sometimes Neither Online Nor Serviceable

404 LOLCAT NOT FOUND by GirlieMac on Flickr, CC BY 2.0The down side of relying upon all these online services is that, well, they’re online services [1]. The sad truth of the internet is that these things disappear all the time, often with little or no notice. Some notable examples:

These are just a few of the innumerable internet services which have either seen their final sunset or been very close to it. Each of these companies had users who relied upon their services, users who were left high and dry when the last staff member leaves the building. And in the end this just didn’t matter. The lights went out and the service disappeared.

This is bad enough for your Average Joe User, but what if your own company relies upon someone else’s API? What if you were one of the companies whose offering depended upon the Google Maps API for Flash only to have it end-of-lifed? Or, say, the Amazon cloud is suddenly unreachable? How would your company fare?

In this interconnected world of ours we are all stronger through the cooperation afforded by public APIs and online services of this kind, however that does not mean we’re allowed to be blind to the risks which we take by doing so. As CTOs, architects, managers and programmers we all need to consider these scenarios and prepare for them in order to minimize the impact on our users. Downtime happens to everyone at some point and is excusable but failure to prepare is not. It’s just stupid.

500 LOLCAT INTERNAL SERVER ERROR by GirlieMac on Flickr, CC BY 2.0When designing your project or service, try to build in some failsafes to prevent a crisis in case an external API or online service becomes unavailable. Fail gracefully, don’t flame out. It could even be as simple as disabling certain pages (or even the entire service, if necessary) when an API can’t be reached. This is a far superior user experience to your users seeing a 404 or 500 status page…

When researching this article I came across the post API Half-lives by Gabriel Weinberg of DuckDuckGo. He has a great list of questions for a team to ask itself when considering APIs and services to use in their projects. Go give it a look then sit down with your team and consider whether you’ve put yourselves at risk and, if so, what you can do about it.

[1] I have taken precautions for each of these services to be sure I do not lose important data. All information is sync’d to multiple locations and, in the case of the photos, backed up in multiple locations as well. [back to reading!]
[2] ArchiveTeam’s raison d’être is swooping in to save at risk data. They do great work and could use your help preserving our fragile digital heritage. Check out their wiki or hop on their IRC channel and say howdy. They’re all rogues with hearts of gold who’ll welcome you with open arms. [back to reading!]

Online Services I Find Worth Paying For

While I appreciate getting something for free [1] as much as the next person, I’m also very willing to shell out cash for online services which I find both useful and valuable. Here are the ones for which I do (or am willing to) plunk down a few shekels on a monthly or yearly basis:

  • Dropbox: I adore Dropbox. This service has saved my ass more times than I care to remember. While the standard service is free for 2GB I pay to upgrade my account to 50GB. While it’s nice to get all that extra space I’ve found that Dropbox has become such an integral part of my workflow that I would pay anyway just to help guarantee it’s around for a good, long time.
  • Evernote: I spend a lot of time online and most of that is spent reading. Back in the day I would bookmarks articles I enjoyed. Back in the day I would also lose the bookmark file any time I switched computers. I also would never look at the site again. I’d remember, “Oh, I read something about $foo once…” but be unable to locate it in the morass of links. Enter Evernote. With one click of the browser plugin any site, any image, any PDF is slurped into my Evernote account, metatagged, indexed and sync’d to all of my devices. Data is no longer lost and I’m a happy camper who’s able to search and locate whatever I need. The basic service is free and more than adequate for most people but, yet again, this is a service which important to my day to day work and therefore worth it to me to support financially.
  • Netflix: Really, does this one even need an explanation? Probably not but it’ll get one anyway. I haven’t had cable for about twelve years now. I’ve been without a TV for two or three years. My entertainment needs are met via the internet, primarily by Netflix (of which I’ve been a subscriber since 1999). Netflix allows me to indulge my desire for cheesy science fiction programming without having to spend money on DVDs which are just going to take up space in my apartment.
  • Github: Github has rapidly established itself as the go-to distributed version control hub on the internet, particularly among open source advocates. Any repository which is open sourced may be hosted for free and includes a project tracker, issue tracker, etc. It’s a brilliant piece of work for which the Githubbers should receive a great many gold stars. I, however, don’t have any open sourced repositories there quite yet. Instead, I pay a small amount every month for the peace of mind which comes from maintaining important files in my own private version-controlled repositories.
  • Remember The Milk: The most important tip I took away from GTD was, “write it down in a trusted location and get it off your mind so you can focus.” Remember The Milk (aka ‘RTM’) is that trusted location for me. Any time I think of something I want to or should do I immediately grab one of my devices, type in a quick to-do item and sync it up. Since I started doing this over a year ago my productivity and organization has increased greatly while my stress level has mostly dropped. When something doesn’t get done it’s invariably because I failed to use the system correctly (like not looking at it; hrm). For a while RTM syncing from iPhone and iPad required paying for a Pro account (I do not believe this is the case now), which is necessary for me to capture items on the fly. However even if that weren’t the case I still would pay for this service simply for all the good things it has done for my quality of life.
  • Flickr: I used to host my own photo albums. That got to be a drag. Not only that, there were new online services which were doing the same thing but better. At the time I joined Flickr was the hot thing and had yet to be acquired by Yahoo!. The user interface was clean and useful, the features were exactly what I needed. Subscribing for a Pro account got me the organizational features I required. Now my account hosts 1,646 of my photos and am well content to stay with them for the next 1,646 and beyond.
  • Spool: This one’s a newcomer to the online service game, so much so that it’s still in private invitation beta. It’s also the only one on the list which currently does not have a fee option for its service and is entirely free. That said, this service has very rapidly become a vital part of my online workflow. While Instapaper enables users to save articles for offline reading, Spool enables its users to save both articles and videos. These are then synced to my iPad and iPhone. I read/watch them on the Muni, in the pub, while waiting in line… The best part is that I no longer have a browser window crowded with “Aspirational Tabs” for things I’d like to get to some day. Click, add to my Spool, close the tab and get around to reading it later. If Spool adds ‘Send to Evernote’ as an option (‘Send to Twitter’ and ‘Send to Google+’ would be nice as well) then I’m a user for life and will pay for the privilege. As they’re still in beta I have great hopes for these features.
[1] Hellooooo, Google Mail, Google Docs, Google Voice, Skype, Twitter… [back to reading!]

It’s Called Marketing for a Reason

Let’s do a little experiment. The next time you’re in a room full of techies, say something along the lines of, “Hey, how about that marketing department, eh?” Now count the number of people in the room who roll their eyes, snort derisively or start otherwise grumbling about how marketing is evil and clueless and a few other unflattering adjectives.

I used to be in that camp. I used to believe that marketing was nothing but advertising and manipulation, getting gullible people to buy stuff they neither want nor need. Then I worked at an online marketing company for six years and took the time learn what this wacky “Marketing” thing is all about.

While advertising is a large (and the most public) facet of marketing I believe it’s one of the least important. Which isn’t to say it’s not important, just that I personally rank it near the bottom of marketing operations.

A hint to the most important marketing operation is right there in the name: Marketing. Before a marketer can do anything else he needs to determine his market. I offer that this is the single most important operation not only in the marketing department but also in the entire organization. Why?

Your market is composed of your users. It’s the people with whom the sales team closes deals, for whom you put code to editor, for whom the customer service reps pick up the phone. These are, as far as your organization is concerned, The Most Interesting People in the World. Before it lifts a finger it must know not only who these people are but also what they need and how to communicate with them.

Do you know your market? Have you ever thought to ask? If not then I strongly suggest the next thing you do after you read this post is schedule a lunch or coffee outing with someone from your Marketing team to do a little learnin’. An understanding of the people for whom you’re writing software will lead to better decisions about design and features, more successful services, better roll-outs… In short, it will make for a more successful project. Not knowing your market means you’re not in sync with the rest of the organization. You’ll waste time adding features which no one will use. You’ll design interfaces which will confuse and frustrate. Sales won’t sell, customer service will be overwhelmed with requests and you’ll have to go back and fix it. No one wants that.

It’s possible that you may already have a pretty decent idea of who the users of your software are and for that I heartily applaud you. However I still recommend you take an hour to have that lunch with someone from Marketing to discuss it. As much as you know you can always learn more. Getting a different perspective on your market can only do good for you, your product and your organization. Furthermore you’ll gain a deeper understanding of the operation of the organization and where you fit in it. And let’s not forget that there are two people sitting at that lunch table. Forging a relationship with Marketing helps expand the horizons of both teams and enables the entire organization to be more successful.

Or, to put it into Marketing Speak, embracing a best practice of increasing interdepartmental face-time to leverage a holistic and synergistic approach to market knowledge can increase the core competency of the enterprise for greater return on investment, mindshare and thought leadership.

OK, so maybe sometimes marketing can be a little bit evil.