Design in a Pinch: Simple Extrapolation

January 31st, 2012 2 comments

My fab sister-in-law is getting married in June, and as is oft the case in my familial circles, I as web guy was a natural candidate to make the wedding website.

“Would love to,” I said to Jen upon her request, “just give me whatever text, images, and design elements from your invitations and I’ll put it together.”

She did a bang-up job in giving me the site pages + content–it was one of the easiest copy-and-paste jobs I’ve ever done.

In the visuals department I got a shot of the wedding venue, a vector art graphic of a monochrome tree which adorns the invites (in a lovely shade of blue, #315683), and photo of the happy couple in Italy, taken in the proud tradition of heads tilted together smiling at an outstretched arm.

In total, this is not a whole lot of guidance, design-wise: a single motif in a single color.  I generally love (and prefer) collaboration with a designer who supplies me with pretty pixels that I get to bring to life in web form.  But in this instance, no such luxury.  I’m not a designer myself, but I can pass for one in a pinch–this makes another occasion in which my experience with and lessons from the exceptional design talent at Playground comes in handy.

Turns out a single color and a single image can go along way to create a comprehensive aesthetic.

By picking a suitable matting color (in this case white to serve as the background for blue text) and picking a darker shade of the same hue for low-lights (in this case #0D2B4C, picked fairly willy-nilly from the ColorZilla color picker), you’ve got a nice base for a unified look of text, image borders, backgrounds, drop shadows, and gradients.  The monochrome motif can be employed in a few places tastefully as ornamentation (in this case, part of the header image and a large content background, muted by a partially opaque white mask).

The result?  Not too shabby, methinks.  From a single graphic and one color, the whole design comes out as an extrapolation: resizing the graphic twice, deriving two other colors and some CSS3 goodness were all design prowess it took to take the WordPress 2011 theme to the end result,  www.jen-and-jason.com.

 

Categories: Design, Projects Tags:

It’s Just Me: Solo, and Proudly So

January 18th, 2012 6 comments

I passed through my early days of entrepreneurship with plenty of rookie insecurity.  One vestige of that era was how in my public-facing prose (such as in contracts and on my website) I’d write things like “We’re committed to the success of our clients’ business ventures.”, “we’ll get back to you within 24 hours”, and references to “our development team”.

I was using the word “we” when the word “I” was far more appropriate, as if the fact that it was just me was some dirty little secret to be guarded.  I had it in my head that, in order to be taken seriously, I better project the air that my company was bigger than it was.

In other words, I was in the “We” trap.

Nowadays, I’m super content and proud to be the product of JPL Consulting: I’m it, it’s just me.  I’m not trying to sell an ethos, a corporate culture, a team backed by a method for finding/growing/retaining talent, or anything else that larger development shops pride themselves on.

It’s just me.  You either dig me as a partner who can do your project or you don’t.

The other week a prospective client was hitting me with all kinds of great questions about how I work, and one of them was “Do you have anyone else that would be working on our project?”  Despite the intuition that they might like to hear that their baby would be in more pairs of capable hands than just mine, I replied proudly that it’s just me, that I’m able to handle elaborate projects from start to finish all by myself, and that things go massively faster for it.

To my surprise she was distinctly happy to learn as much, and cited how she and her partner have worked with consulting firms where they liked their initial contact, but once they signed a contract their project was handed off someone else who, in their estimation, wasn’t nearly as good.

That I was their agent for the project, period, was good news.

This makes sense: with any consulting firm that’s organized sensibly, the person you talk with up front to get your project rolling is going to be the strongest person that the firm can offer you.  They are the closer.  If, when you’ve signed on the dotted line (effectively saying yes to that company with confidence that they can handle your project), it’s someone else who actually executes your project, chances are good you won’t be as impressed.

By contrast, in a one-man shop, the one who sells you on their ability is the one you get.

If you have a good impression of me as I take you through the upfront consulting/sales process, then it’s good news that I’m the one who will be actually living up to my words1.  Accountability is in a nice tidy little package, and there’s no one else that the buck can get passed to.  Sure it sucks if I get hit by a bus, but even that has a workable plan to it.

To solo operations everywhere, I say this: you can either put on the facade of being bigger than you are, ashamed to have not yet built your empire with hoards of underlings, or you can grow yourself to the specific reason people are excited to work with you, and proudly tout as much in your conversations and prose.

Your call.

Notes:

  1. This, incidentally, eliminates the cliche of sales people making promises that can’t be fulfilled.
Categories: Essays Tags:

Introducing trueDAT4

January 12th, 2012 No comments

God bless open source software.

By now I think folks who are cognizant of it at all pretty much know and agree that it makes the world a better place.  I think there is no better way to experience this than by taking stock of the open source contributions which have helped you while making one of your own.

trueDAT is the home-brewed database GUI tool that I’ve been using for over 8 years now.  The original tool to go by that name was conceived by Charles Guthrie back in ’03, in Classic ASP.  It was then a roguish way to get development work done on a network of servers where the admin overlords expressly forbid the installation of a more conventional and heavyweight solution like myLittleAdmin, and I loved the spirit of taking matters into one’s own hands and crafting the tools necessary when other solutions were unavailable.

In early ’05 as I was getting my own chops at web development I took a crack at writing a version 2.  I wanted to add a few useful features which I knew would be useful after months of working with the original.  The notion of creating things to scratch your own itch (as brilliantly articulated by 37 Signals) is a powerful premise indeed.

Three years later, with the sexy possibilities AJAX and MooTools well under my belt, I created trueDAT3.  Lee Robinson, one of my design peeps at Playground Creative, provided me pretty pixels so that my database tool would be a little zen garden of a workspace.  I don’t know if you know this, but a lot of developer tools are ugly, spartan, rough on the eyes (trueDAT1 and 2 were no exception!).  I realized then that developer tools should be sexy.  They make the work that much more enjoyable.

Now, three and a half years later still, we are at the current day.  I’ve matured a bit as a web craftsmen, enough to take real stock of all the contributions which have been made to me by complete strangers who thought well enough of the world to share their teachings, code, and skill.  Doing so makes me desire deeply to give something back, and thus I figure perhaps some good will come of sharing trueDAT with the world.

Version 4 adds in the features which I’ve come to recognize as useful after years of enjoying the last one, and opens things up drastically to be a bit more openly applicable for folks.

The result can be found at trueDAT’s own little website, truedat.us.  There you can tour the features, download the source, demo it out on a database filled with data that you don’t care about, and even go fork it on GitHub.

I have no idea how many people will ever use this, or even if it will ever catch on in any significant way.  Before any of that happens or doesn’t happen, though, I sit here now super satisfied to have put this all together as a gesture of following in the footsteps of my heroes of this trade.

Here’s to the great contributors of open source, who by their generosity have taught and given us all so much.

Categories: Projects Tags:

If I Say “No” to Your Project

January 2nd, 2012 No comments

Like everyone in my profession I get approached by folks who are interested (or at least potentially interested) in hiring me to turn their business vision into a live, working web application.

If all of the maxims of self promotion (the vital importance of networking, having strong references, keeping clients happy so they’ll continue to hire you, etc.) are true (they pretty much are), it is of course in my best interest to say yes to any project that (a) I’m qualified to do, (b) I’m available to do in the called-for time frame, and (c) my price is acceptable for.

Saying “no” based on any of these criteria isn’t terribly interesting as most everyone holds to those three prerequisites for accepting work (though based on the regularity of client horror stories with their past vendors, it would appear that a lot of folks in my profession relax a little on point (a), but that’s for another essay).

What’s more interesting is saying “no” to a project when, by all conventional measures, it amounts to good, gainful employment while providing a client with what they know they want.  I do this now and then, and I do it specifically when deep down I don’t believe in the project.  When yes, they’ve got the money and yes, they’ve got the drive and vision enough to pull the trigger, yet I can’t wrap my mind around how this is ever going to work in the envisioned capacity.  This is when my conscience pipes in, objecting to thought of taking money for a project that I don’t believe will ever bear fruit for the individual or organization willing to pay me.

Am I fallible in my estimations?  Absolutely.  I don’t pretend to know for certain how things will turn out.  But I have done enough projects that had a lot of heart and a compelling vision which turned out to be ultimately a poor idea (and in hindsight could have been recognized as such with knowledge available at the start).  For it I can recognize hints of blind optimism when I see them.  Red flags of assumptions or impending obstacles that are unaccounted for jump right out and insist upon careful consideration before I can dismiss them.

This, while perhaps annoying as rain on someone’s parade, I believe is to everyone’s benefit.  My being unwilling to take a client’s money and diligently complete the work when I can’t get behind a project might be the most generous bit of consulting I can give when confronted with a flop1  If I send you back to the drawing board because I think the project has major weaknesses2, I might well be viewed as insolent and unworthy of hiring in the first place.  But deeper than that, I might well be doing you a huge favor, helping you to either (or both) save a lot of money & time, and refine your ideas so that they do ultimately succeed once a guy like me is brought in to bring it to life.

Though it breaks my heart to turn down good gainful employment, I do not hesitate to render this favor when appropriate.

By corollary, if I’m excited by your project and think it has legs, I’ll tell you as much and (if you care to hear it, most people do) explain exactly what specific merits I see it having and why.

There’s probably a good litmus test in all of this.  Useless flattery to lobby for getting a contract is bankrupt.  If you wanna sense for how much your success matters to your developer, throw a deliberately terrible idea their way and see what they think.  Whether they they greet it enthusiastically or balk at it, ask follow up questions and you’ll really learn something about who you’re talking to as a service provider.

If I say “no” to your project, take it as a sincere gesture of commitment to its success.  My doing so might either help you dodge a bullet, or prompt you to retool your vision in a massively useful way.

Notes:

  1. Again, “a flop” by only my own estimation.
  2. I make myself available to help work through this sort of thought work, if desired.  It’s generally fun and super satisfying.
Categories: Communication, Essays Tags:

Cheap Overseas Programming Revisited: Takeaways from a Lively Community Discussion

December 21st, 2011 13 comments

My earlier essay about cheap overseas programming (with the observation that it’s not all it’s cracked up to be) ended up sparking long comment threads in places like Hacker News, Slashdot, and Reddit.  Thanks everyone for weighing in on this one–this turned out to be a topic that touched a nerve with folks much more than I had imagined.

There are a number of themes that kept coming up in the threads, and from them I see a few ideas worth exploring.

A number of comments were to the tune of “What did they expect at $12/hour?  This is not news.”  I take it as a positive sign that disaster in cheap outsourcing of software is self-evident for some, yet based on the multitude of folks weighing in with similar stories of cleaning up outsourced messes, it’s clear not everyone has gotten the memo (most programmers I reckon have, hiring managers less so).

A number of comparisons were made comparing the attitude of the essay to the hubris of the US auto industry back in the 60s and 70s: the local talent giving themselves a pat on the back, celebrating their infallibility, while competitors abroad were gaining ground, the implication being that local talent would one day eat their words and regret their complacency.

I think this quite insightful, but it misses the alternate dynamic which I think is at play.  Back when I was in grad school for computer science (2001-2003), the talk among our soon-to-be-graduating ranks was that the job market is tough, and usually close behind was that the US programmer was a dying breed, fast losing jobs to overseas markets.  This we heard peddled without apology or qualification, it was just a sort of accepted reality as described by the “experts”.

So in regards to the 60s/70s auto industry comparison, I say the scenario more resembles this: the local talent has been told “you’re fucked, don’t even try”, and after a decade of experience we are now witnessing that it ain’t necessarily so.

This is not so much a tale of complacency so much as reclaiming a sense of relevance in industry.

As many commentators rightly pointed out, my limited experiences do not constitute any statistically valid conclusions.  Quite true, but those experiences (and the many similar stories shared) are enough to counter the sweeping narrative of the impending death of the US programmer from years back.  The death of the US based programmer was like the sensational story that breaks on page one in huge type face, only to eventually be followed up by a redaction tucked away on page 13 in a much smaller font.

(Tangentially, I suspect the talk of US programmers being unable to compete on a global market caused an untold number of students to veer away from computer science degrees, and by corollary a counter narrative might serve to veer students towards computer science.  A useful re-balancing, I think.)

In the end I think the most well-reasoned comments came in the flavor that is well summarized by @dylanized‘s words:

I’ve got programmers and designers I work with in India, Pakistan, the Philippines. The guys I’ve found are badasses, very professional and teaching me stuff all the time. If and when I become successful, it will be due in large part to my overseas team.

I’ve also attempted to recruit horrible programmers and designers before. Sometimes they come from these non-western places, other times they come from America or even from my hometown.

There’s jokers everywhere. It’s up to us as technical project managers to screen them out and only hire good contractors and firms.

To me, that is really at the heart of it: it takes real talent to do this work efficiently and economically, good talent can be found anywhere (as can terrible talent), and that good talent should be sought after and prized above all else for businesses with projects that matter.  Though it runs counter to hopes of scoring a real bargain at $12/hour, programmer types can probably all agree there is a lot of depth to the art of being a great on-demand programmer.  The notion that it’s grunt work which can be given without care to the lowest bidder is a farce.

Long live the truly talented programmer: this conversation reveals perhaps above all else that they are in short supply the world over.  To those who choose to continuously deepen their mastery over the craft, I say let us take to filling that need.

Categories: Essays Tags:

Why I Will Never Feel Threatened by Programmers in India Cheap Overseas Programming

December 4th, 2011 228 comments

[UPDATE: To all those who got here by clicking a link entitled “Why I Will Never Feel Threatened by Programmers in India”, that title has been retired as an unfortunate misfire on my part: much of the conversation was lead astray as though I meant to single out India in particular, and it landed for some as having racist connotations.

It is now titled “Why I Will Never Feel Threatened by Cheap Overseas Programming”, which much more aptly captures the meat and message of this essay.  And now without further ado…]

I got a call from a friend of a friend the other night. It was a fellow with whom I’d talked 11 months ago about a project he and his partner were looking to start. We established then that I wasn’t the guy for him, that I was likely too expensive for their big-dreams, small-means budget.

Fast forward to present day: their project is still not launched, it’s still not right. They’ve paid for something between 600-700 hours of development with a firm in India, and they should have launched 6 weeks ago.

Sure they’re only being charged $14/hour for that work, but I think the Indian firm is, as the saying goes, making up for it in volume.  And that’s to say nothing of the time our heroes have spent proctoring the whole process: in his words, they’ve got to be constantly super explicit in their instructions, or it comes back wrong–then then have to spend more hours getting it fixed (this is but one instance of why I am suspect of the hourly model in my industry).

“I’m wondering if you’re available–my partner says we just need an American programmer to get in their and clean up a few things to get us out the door, we figure it would take the right person 10 hours, instead of 50 or more with these guys.”

Outsourcing programming came in to vogue as a cost-effective strategy, what, 10 years ago?

For a number of years in my industry there’s been a sense of not-necessarily impending doom, but something akin to that due to the rise in outsourcing programming work abroad, most prominently to India.  Hoards of smart people, as the alarmist vision goes, willing and able to do highly talented technical work for a fraction of the going rate for US programmers.  The labor force here in the states can’t possibly compete, and what savvy, responsible company could possibly pass up the opportunity of such cost-effective globalization?

The thing is: I have yet to see a project done overseas at that sort of hourly rate that has actually gone well.  Version 1 of MonsterMarketplace was first done overseas–took 4 months, billed for gobs of hours including a lot of testing and QA, and crashed predictably under the strain of campaign traffic.  (By contrast, my complete rewrite of the front end was done in 4 weeks–at peak times it produced about 4% server CPU utilization, never crashed, and had correspondingly faster page loads.)   This was my first inkling that the “outsourcing problem” wasn’t all it was cracked up to be.

My second close look at the outsource phenomenon was the code base for Zowzee.  As I discussed in the tale of building and launching SpotlightDenver.com, rebuilding it made more sense than trying to extend the $12/hour piece of work (to this day I’ve been too polite to ask how many of those $12 hours it took–I do know that my work was vastly cheaper, faster, and smoother).

And now this.  That makes three out of three instances in which outsourcing abroad turned not that great, if not outright regrettable1.  This is a small sample, to be sure, but still serves to bolster my confidence as a US-based programmer.

Reclaiming our Competitiveness

So how is it that we can compete with programming talent overseas, with figures like $12/hour stacked against $125/hour?  My experience leads me to believe that US-based programmers can be the sound and “right” choice for development projects, and we don’t even need to resort to protectionist arguments for supporting our local economy & talent.

I think we can observe a few generalizations which, while they may not give due credit to the exceptional firms overseas, serve to counter the equally general notions that hiring offshore talent is an economical no-brainer.

Consider the idea that the rock-bottom hourly rates creates a certain cognitive dissonance in decision makers.  If I tell you that your job is going to take 500 hours, but don’t worry, it’s only $14/hour, you might think it a god send that such a rate is even possible–you might even think it not worthwhile it to consider US based options at $50+ per hour.  Sure, the quote from India might be a little inflated, but it couldn’t be that inflated… right?  Turns out it was in my 3 examples.

But even if multiplying hours times rate gives you a real bargain, there’s a very good chance the hours term will balloon.  If they get something wrong, they can fix it with 20 more hours of work.  But don’t worry, it’s only $14/hour.  Again, impaired judgment based on what a great deal you’re getting makes this palatable and thus probable: you wouldn’t tolerate it if you were paying a substantial hourly, and besides, you’re already in 500 hours, so what’s a few more?  I think it’s safe to presume that overseas firms understand this reasoning and mindset very well, and at very least appear to exploit it accordingly.

Our heroes’ need to be super explicit in order to get what they want reveals another major advantage that local programmers have: nobody wants to have to babysit their programmer with constant direction and correction.  Communicate the overall vision of what you’re trying to create for your customers, and any programmer worth their salt will bring their A-game to solve it from that shared understanding.  The net result is a project that is completed faster, racks up far fewer billable hours, and saves you headaches and time.

I’ve noticed a number of other reasons to think twice about off-shoring:

  • real-time communication made inconvenient and response times made long by the time zone difference,
  • a reduced sense of accountability, commitment and partnership inherent in the long distance relationship,
  • and text like “Link will be sent to your mail for to update your Password.” sprinkled throughout public facing parts of the website, which just doesn’t give your customers the best impression of you and your business.

These all come with the turf but seem seldom considered: the allure of cheap labor seems to trump these potential problems, or they are unimagined all together.

The good news is that each of these reasons constitute a means by which US programmers can justify their value as a worthwhile and economically sound alternative to outsourcing.

There’s fruit to all of this on more idyllic grounds, too: just as the threat of overseas outsourcing would tend to discourage mastery of programming here in the US (what’s the point when you’re told that someone else is going to eat your lunch?), the notion that the fight is more fair than typically envisioned may as well encourage it.

I believe when the myth of cheap, abundant programming abroad is shattered, there is a lot more reason for the next generation of talent to take on and excel at a craft that creates real value.

[UPDATE: There has been a lot of comments and conversation on this topic here and elsewhere.  See the response to many of the consistently raised issues in the follow up post, Cheap Overseas Programming Revisited.]

View the discussion on Hacker News or Slashdot or Reddit.

Notes:

  1. To be clear, I’m focusing narrowly on substantial programming projects.  I don’t doubt that outsourcing has been effective with other, simpler web work.
Categories: Essays Tags:

Sometimes You Gotta Rebuild

November 27th, 2011 2 comments

This is project that was a long time in coming, and in a short time in doing.

I first became acquainted with the Zowzee team back in January when I went in to pitch on their then new project, DealNation.  Frustrated with the progress and process of working with a firm in India, they wanted to know if, in addition to building DealNation, I could expand their Zowzee application (built specially as a deal-of-the-day site) to be more of a general purpose marketplace of deals: let deals run for longer than a day, enable visitors to peruse and purchase from a collection of deals, and so on.

Tempting as it would be to pick up the extra bit of work, after poking around the code I had no interest: it was buggy, carelessly architected, and loaded with code duplication (meaning if you wanted to change something, you better be sure you found and updated every instance of it, or face new bugs and inconsistencies).  I couldn’t responsibly quote prices or time frames for any non-trivial work, to me it would all be subject to pitfalls and gotchas.

I said to Paul with earnest sympathy and apology (because I know it sucks to get the kind of news I had to give) that it would need to rebuilt if I were to make any substantial changes on it (I mean, who wants to hear that 3 months after you launch?).  I scoped it out and wrote it up, and estimated a solid two weeks to do everything and add in the big new features.  “But at that point” I told him, “you’ll have a super solid foundation from which point I’ll be able to make it do whatever you want, easily and without concern of introducing obscure bugs.”

Paul was open to it (a real testament, I think, to how it was going with the firm in India) but it was not in the budget at the time, thus Zowzee would trudge along in its current state for a while longer.

This month, with me now in house as CTO of DealNation, we found gap enough in my usual duties to direct our attention back to the Zowzee redesign: our sights were now to reincarnate it as SpotlightDenver.  Paul took the initiative to mock up some fab wire frames that really gave a clear vision, hired some design help to give me some pretty pixels to work with, and we were off.

Centered around the concept of a marketplace of deals, I built an e-commerce application nearly from scratch that was perfectly tailored to the needs in just over two weeks amidst usual DealNation duties.  The end result is www.spotlightdenver.com, launched Monday, November 21th.

My team tells me that the whole thing went smoother for them than launching some of the deals on Zowzee, let alone the whole Zowzee site.  And the best part for my team is me delivering on my original promise of the rebuild: we’ve now got a super solid foundation that is easy to extend upon, and since launch I’ve been taking requests and building out new features that make everyone’s life easier and better.

The whole experience has reaffirmed for me that yes: though generally unpleasant news upfront, sometimes you gotta rebuild.  The good news is the other side can be quite gorgeous, workable, and profitable.

Categories: Essays, Projects Tags:

The Joys of High Visibility Micro Goals

September 8th, 2011 2 comments

I like to create games.

Games that motivate.  Games that create focus, pressure, supreme concentration.  Done right they can be a fantastic hack for programmer productivity.

A few weeks ago I set out to build a working prototype of the DealNation members zone in a single day.  To make it interesting, I let everyone in on the game.   At 9:45am I setup my day as a collection of mini-milestones in building the system from start to finish, each with a target completion time, and put the progress chart + time line on the office whiteboard for all to see.

I had declared my fate for the day, and effectively given my word to “this is what will get done with every passing hour today”.  Folks were curious to get that kind of high-resolution look into how I work, and I promised they could view the work in progress as I pushed each mini-milestone to our dev server.

To make it more real and pressing, I openly advertised my progress throughout the day.  When a milestone was completed I would rise from my desk, write the actual completion time on the whiteboard, and settle back into my trance-like concentration at the computer once again.  No chit-chat, I was on a mission and everyone knew it.  Green marker meant I was on time, red meant I was behind.

At the end of the day, this is what everyone in my office got to see:

Yep, I gave it a zany, over-the-top name. Whatever, it's my game.

There are a lot of payoffs to this structure.  First, this day was a ton of fun for me.  It was like being in the zone of pure productive concentration for a hour, 7 times over.  I had zero problem blocking out distraction, and the mini-race to the next milestone keyed me in with renewed focus each time (it’s WAY fun to write the next actual time on the board, and striving to use the green marker keeps it interesting).

The final show off was the grand prize.  My team was delighted to see all that got accomplished in just one day, and I think their sense of appreciation was heightened by being vicariously in on the process along the way. This is about as close I know to the experience of performing for an audience as a programmer, and it creates a certain buzz which theatrical and musical performers will understand.

Categories: Communication, Essays Tags:

Taking a Position as CTO of DealNation

July 7th, 2011 No comments

I’ve been invited to join the team of DealNation as their CTO.

This is a very good fit in a lot of ways, most of all because it has me doing my magic in a way that lends rocket fuel to a big venture that’s already got a lot going for it.

In retrospect there are 3 things I would say I did very right to precipitate this opportunity:

  1. I set the bar for my performance very high from the very beginning.  The first impression I made on the DealNation team was an act of remarkable ability, and I, with confidence bordering on arrogance, stated plainly then that that’s just how it goes with me.  I’ve been delivering on that tall promise ever since.
  2. I gave them a taste of what it’s like to have me in house.  When I offered the free day of me working with them side by side on my laptop, they got to experience the luxury of immediate communication to bounce around ideas, and the velocity at which development can get done when you sidestep the spec’ing/bidding/approving cycle of contract work1
  3. I shared with them a single-sheet write up of the value of me being their CTO. Drawing heavily from the coursework of Ramit Sethi’s Earn1K, I took the time to really articulate the how and why I could be of most value to DealNation in the CTO capacity.  Then I unabashedly shared as much.  Two months later, when the time was right, they came around to taking me up on that offer.

The path that we’ve taken together since January has us both clear that we’re a fantastic fit, and thus I’ve accepted the position and begin on July 11th.  Exciting times ahead, I can hardly wait to weave more web dev magic into everything they (soon to be we) are doing.

Notes:

  1. I’ve been hired to come in a few days since, so even before being offered the position of CTO it was clear that this was a hit.
Categories: About Me, Business Tags:

Knockout First Impressions

June 15th, 2011 No comments

“Dude, that was a total baller move.” my friend Eliav reminisces of it, months later.

This refers to the manner in which I first met the good people behind a young company here in Denver called DealNation back in January.  As a close collaborator to the project, Eliav got me invited to pitch myself on developing their system.

Things moved fast this particular week in January.  While hosting and hanging out with Eliav on Tuesday night, he loaded onto my browser a few mock up images of the system.  During that same evening I got a call inviting me to come to the office and pitch on the project.  We would meet the next day, at noon.

Fast forward to 9am on Wednesday.  I’m all ready to go, and have about 3 hours to kill before I meet with some strangers to convince them that yes, I have web development superpowers.

An idea hit me.  I checked my browser’s history from the night before looking for the mock up images.  Bingo.  Instead of pacing about for 3 hours, psyching myself out for what is in essence a job interview, I would spend the time building a working prototype of the system as a real-as-can-be demonstration of what 3 hours of John Larson time are worth.

It was an inspired 180 minutes.  I fired up Photoshop, sliced up the mockups, designed a suitable database, whipped up the 3-step front end user experience, and even created an administrative back end for configuring facets of the system and viewing results of user visits.  A quick deployment to a dev URL and I was out the door for my noon meeting.

Like any such meeting I was met by the usual platitudes of greeting and new acquaintance.  “Hi John”, “Good to meet you”, “Thanks for being here”, “How’s it going?”

I was waiting for that last one.

“Good”, I said, “I’ve had a fun morning.  Now I’ll be honest to say that Eliav shared the mock ups you guys are working on with me last night, so I’ve had a little advance info on what you guys are up to.  I had time to kill before this meeting since 9, so I cooked up something I think you’ll find interesting.  May I show you on a computer?”

As I punched in the dev URL in the address bar, I continued to say “So I built your system.  I mean not all of it, and it’s not the air-tight, bullet proof masterpiece that you could expect with a more thorough effort, but enough to give you a good sense of what I’m capable of in a few solid hours.”

I let them play around on the front end, and had them log in with their own username and password in the back end and see the several controls and reports available in this hurried piece of web work.

I went on to narrate: “Now I understand you guys are used to paying twelve bucks an hour with India, but perhaps you will find me worth the roughly $125 I charge1–you get a bit more bang for your buck, I reckon.”

With them clear that I was the real deal, the rest of the meeting was a fun, free flowing exchange of ideas and everyone getting to know each other.  Again, this was Wednesday.  Later that afternoon I had a proposal with firm price tag in their inbox.  Thursday I had the thumbs up for the project, and on Friday I dropped by to pick up my project inception check.

The powerful first impression set by those 3 hours of work set the tone for our entire working relationship, namely “you can and should expect miracles of me that will defy what you’ve been trained to expect in software development”.  By the gesture I deliberately set the bar for myself very high, and to our mutual delight: they get to enjoy ultra-high performance out of me on a regular basis, and I get to delight in the opportunity and rewards of providing it.

Notes:

  1. I don’t do hourly, as you may know: that’s just my rule of thumb for estimating project costs
Categories: About Me, Essays Tags: