Programmer for Hire

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.

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 words¹.  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:

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.

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 flop¹  If I send you back to the drawing board because I think the project has major weaknesses², 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: