Programmer for Hire

I’ve been a programmer for hire for a number of years now, and in such a broad field as software development, it’s taken me some time to converge on a succinct description of what it is I do, especially one suitable for non-technical folks.  But I think this sums it up:

I design and build software that powers businesses.

This line contains a lot ambiguous connotations in my field, so in the interest of clarity let’s break this down one key word at a time.

I.  I do the work that I am hired to do.  I don’t sub-contract my part out, I don’t manage the projects for others to  execute.  The projects I am hired for are executed by me, made with the love of a craftsman who values being able to hand over completed work that is a proud expression of what I am capable of.

Design.  Design is often taken to mean the pretty pixels: color schemes, imagery, graphics, styles.  That is not me: I take my aesthetic cues from the established brands that hire me, or the designer my clients are using, or one of the graphic designers that I recommend.  I’m talking about design of user experience, functionality, solutions to the real needs.  This means my clients don’t have to feed me a lengthy spec doc brewed up at great effort & expense, their mere knowing they have a need is enough to get the conversation rolling.  I play the role of collaborator responsible for designing an effective solution.

Build.  I build the software that I am hired to create.  That means I’m intimately familiar with how it’s going to go in terms of time and money.  It also means I can intelligently contribute to the design process, attuned to what will be low hanging fruit and what will be more hassle or expense than it’s worth.

Software.  Interactive stuff that runs on a computer or other smart device.  Generally complicated, usually custom tailored, and always web-based.

Powers.  The software that I design in build plays a vital role in the functioning of businesses that hire me.  Real results depend on it, either as internal tools for operations or public facing software that customers need to use and love.  Clunky or hated or hacked together work is not an option.

Businesses.  Organizations rely on the software I build, my fee is worth every penny and priced well compared to less nimble firms, and with projects starting at $5000 I am generally not suitable for individuals to hire.  I work for businesses where the stakes of successful execution are high.

That’s what I mean when I say I design and build software that powers businesses.

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 work¹
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:

“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 charge¹–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:

Just for show and tell, here’s a tidy example of what web application development prowess can achieve to bring more life and vigor to a project:

http://www.beingawesomeisawesomefest.com/

Being Awesome is Awesome Fest is something I created as part of coaching a leadership program with the folks at Landmark Education.  Using the fantastic design work of Anne Richardson, I took about 2 days to create a website to power the project: user profiles, project submissions, status updates, email communications.

I had an enjoyable meeting with a peer of web dev wizardry the other week.  He was illustrating a development framework for web apps that he created, talking me through the many layers of the architecture.  While enjoying the discourse there was one small thing that he said that I thought profound: “no one’s a master of the entire [web technology] stack”.  He said it so matter-of-factly, no big deal, just a transition sentence to frame an illustration of the beauty of one smart abstraction or another in his framework.

No one is a master of the entire web tech stack.

(For those of you not familiar with such nerd speak, the “stack” we’re referring to is the several varied technologies, each layered upon the previous, which collectively comprise and power web applications.  Server runs upon operating system, database runs on a server, business logic uses database, and so on.)

No one is a master of the entire web stack. Conventional wisdom.  Self evident.  But of course.

I disagree. My musings in the last few months have led me to curiosity about my staunch opposition to conventional wisdom that [non-trivial] application development requires a large team, large budget, and long time lines: am I full of it?  Is there something I’m missing? Where’s the loophole?

Mastering the entire stack might be that loophole.

(A quick technical caveat for the nerdy purists in the house: I don’t pretend that I’ve mastered the literal entire stack, for example I know only a little about the L in LAMP stack¹.  But since you do things nearly identically on the so-called WAMP stack (swap in Windows for the operating system), I don’t think my craft suffers for it.  This suggests there are some shortcuts one can take while effectively maintaining mastery over the technologies that make a difference when creating web applications.  Similarly, one can get by with only crude [or even zero] knowledge of, say, hardware level logic gates and assembly language, which are also part of the rigorously defined entire stack.)

For this discourse I say the entire web stack that matters in web application development is comprised of: database, server side language, HTML, CSS, JavaScript, and enough knowledge about server software and hardware performance to not be blindsided by rookie mistakes nor dumbfounded by scalability challenges.  That’s it, and there is plenty of depth and mastery in each of these layers.  Regarding this web stack, my friend was approximately right: developers who are masters of it all are super rare².

This I think may be my loophole.  In a world where designations like “database admin”, “front end developer”, and “back end developer” comprise commonplace job titles, it’s obvious that most teams and individuals in my trade are sold on segmentation of skills along slices of the technology stack as the best way to do it.  Specialization and depth over broad, general skill sets.  Makes sense, our civilization has been going in that direction for centuries.

But does it need to be?  It’s certainly not ideal: communication overhead and inflexibility makes it easy for me to best most teams on price, time and quality, I have enough client horror stories to assure me of that.  So then is your average developer stuck in a niche, unable to branch out their mastery because it’s too much to handle?  Am I just a genius?  I don’t think so.

I think above all it’s a matter of just trying.  Overcome that little voice in your head that says “who am I to design a schema without the fancy title of Database Administrator?” and just do it³.  Play with a nice JS framework and make some cool AJAX stuff happen on the client side of things, most of the hard stuff is done for you anyway.  Learn a few CSS tricks and experiment with making things pretty instead of stark utilitarian.  I bet the average pigeon-holed developer could explore in other parts of the stack and be at least baseline proficient in all of it with just a few weeks of dabbling on the side.  It’s those Renaissance-type developers that you really want.

Notes:

A fair question indeed.

I bill myself as an ultra effective development team of one, citing of course virtues like eliminated communication overhead, a shorter route from business vision to application design and implementation, nimble ability to adapt the application to changing business needs when they come up, and 100% accountability when it comes to turning out quality.

Oh, and it’s cheap to hire one person instead of six.

So naturally it has occurred to my clients on more than one occasion to ask me “what happens if you get hit by a bus?”  If I’m the guy who’s doing it all, naturally I represent a sizable single point of failure.

Here’s my answer.

You replace me.  Though I do have a publicly documented love affair with Classic ASP, Classic ASP developers are a dying breed, so it would be irresponsible to start any new substantial project for a client in that language. No, anything that’s built to last I would start in PHP or perhaps Ruby on Rails, languages that boast thriving communities of developer talent from which you could draw to replace poor old mangled (or dead) me.

Now then, when you replace me my successor will need to be trained on how to work on the code base I’ve laid down.  If I’m NOT dead I can guide them through to get them up to speed quickly.  I if AM dead the good news is that my code is quite beautiful and well organized, with perfectly uniform indentation and formatting, completely consistent conventions, and immaculately well factored.  Any developer who is worth their salt in the language I have laid down will be able to understand, trace, and build upon my code within one day of poring over it.  (If not, fire them.  Trust me.)

Furthermore, whatever I did manage to complete before carelessly failing to look the other way while crossing that hypothetical street will constitute a massive leg up on your project.  Remember, typical development projects tend to be heavily loaded on the front end with meetings, spec docs, planning, project management, and other such things that don’t get you closer to a usable piece of software.  Before that Greyhound sent me to a better place even a half-completed prototype done by me will have enabled you to shortcut through all of that, leaving you with a sensible solution strategy and design foundation already in existence.

So in conclusion: if I get hit by a bus, you replace me.  You’ll miss me as you move forward at not as smooth or fast a clip as before, but your project will have gotten the benefit of my precious last remaining pre-bus-hit days.

It’s kinda like getting Frank Lloyd Wright to draw up the plans for your house and then he can’t finish it.  It’s still gonna be a pretty snazzy house even if some junior architect needs to rough in details like which tiles to use in the bathroom.

I recently quoted $250 in response to a client with a particular feature request.  The reply I got was asking if I could add this feature for $125, citing perfectly good and valid reasons of it not seeming like that much and a desire to keep costs down.

Here is my exact reply:

Nah,

Whenever I let a client name the price I turn into a poor businessman indeed, and it puts me on a slippery slope of devalued self worth trying to please clients who will nickel-and-dime me and don’t really value my time.  Most damaging is that it tends to prevent me from doing the great and interesting things with my talents that I’m committed to doing in this lifetime.

Poetic waxing aside, I have a LOT of real world data that the price I charge for the value I provide is above-average fair and, relative to other vendors, sometimes ridiculously cheap.

Now then on this particular price, I’m not hosing you to make a couple extra bucks as though I were a shoe-in for the work: between transitioning mentally from other projects, sorting out your request, pre-pondering the best solution, doing the coding (which I reckon is what you figure should cost $125, and reasonably so), testing it, launching it, testing it live, being generous with any tweaks/enhancements you might request (has it been your experience that I’m fairly generous with these?  It is my aim that it has, and please let me know if I’ve fallen short!), and the sliver of added complexity that it entails for future maintenance/trouble shooting, I stand by my estimate of 2 hours.

(A common alternative to this is quick, get-er-done style work where one change breaks something else, perhaps familiar to you! :)

That said, you might have noticed that a lot of items in the list of things above represent the overhead of doing a non-trivial amount of work of ANY size, and you would be right to think that that sort of overhead is roughly constant no matter how much substantial work is to be done.  I do my best to have evolving and tweaking a system be as fast, easy and painless as possible (and I understand I do pretty darn good at it relative to my industry), but the general rule still always holds: that we’ll both always get a better value for our time and money the more you can batch feature and change requests together (a full day’s work in my experience is generally the tipping point).

Whatever you think for this one is totally cool by me.  If the day ever comes that you want to transition from me for any reason, be it price or whatever (or in the event that I need to move on myself) I am completely reliable to be 100% cool and helpful in facilitating that transition.  I’ll even train the next guy on the code and be available for quick questions (in the past for clients I really liked I’ve even done this training for free).  I’m committed that you NEVER have the experience that you’re stuck with me when you could do better.

Whew, that’s lot!  I didn’t mean to talk your ear off with the above, and know that I don’t mind your request at all.  Hopefully you’ve gotten some nuggets on how to get the best bang for your buck out of me.

Cheers!
John

Looking back there are a lot of things about this communication that I like.  It is a candid look at how I work with and honor my client relationships that I am happy to share publicly: it gives some insight as to how to get the best value of out me, reveals that a lock-in is NOT part of my business model, and gives the freedom to choose.  Negotiation-wise there are a lot of points made and I want to add a few more to round out the exposé of my thoughts on the matter.

My stance on not negotiating price serves both me and my clients because it keeps me honest and true to my standards.  Coupled with my willingness to facilitate anyone in transitioning to another developer, it holds me to a standard of being the best and giving the grade-A experience of working with me. If I don’t perform at the level I say I do and thereby someone can get a better value with someone else, I will lose that business and I should.  Short-cut jobs with me are simply not on the table, though the option to get one somewhere else is.

Psychological factors play into it as well.  When I know I’ll be earning what I feel I’m worth for a piece of work, it’s easy and a joy to put the shine on it and go the extra mile, and my clients regularly reap the benefit of this.  By contrast, in the past when I’ve allowed myself to get beat up on price I had to fight against the devil on my shoulder telling me that just meeting the spec-doc minimums was acceptable.  I always won, but those then were the clients I eventually fired.

If nothing else, not negotiating on price forces me to work with the right clients.  For a mom-and-pop business looking to get a website online, I’m expensive.  For a million-dollar company for which custom software is an integral part, I’m cheap.  In some cases ridiculously cheap.  So if I’m getting push back on my price, it’s a sign that we’re not a good fit, and acknowledging that sooner than later is useful for both of us.

And in case you were wondering, my rate of $250 was accepted via email reply 14 minutes later.

Here’s an actual email dialog with one of my favoritest clients, identifying bits changed to honor confidentiality:

We have an idea for a SuchAndSuch iPhone app. Can you recommend a great developer?

Yep.

Mother fuckin’ me.

John

That’s what I like to hear. We’ll chat soon.

There’s something great about knowing you are completely qualified to take care of someone’s need, and communicating as much in no uncertain terms.

Classic ASP.  Microsoft’s lofty first vehicle to try and corner the market web application development tools and technologies.  It plateaued in November 2000 with it’s final release version, 3.0, and was superseded by ASP.net in January 2002.

And the world was largely happy to be done with it.

Today, 9 years later, it is by all reasonable accounts a washed up technology.  Any mention you hear of it these days in blogs or tweets is most likely from some poor soul lamenting being saddled with doing maintenance work on a legacy system.

Yet here I am, in 2011, and I find myself oddly capable of doing substantial projects in in still, and it DOESN’T feel like pulling teeth.  Between that and my profound distaste for the new-fangled ASP.net which technically I should love by now, I stopped to wonder why.

It’s true that VBScript, the language that predominantly powers ASP, is a not a great language.  And ASP, with it’s very loose and tumble style of negligible structure and convention, makes possible ridiculously sloppy form.  Its simplicity means a low barrier to entry, so there’s a lot of terrible code out there banged out by highly mediocre programmers.  So ASP as a relatively immature environment got a bad rap for some good reasons.

But that’s all part of why I love it.  Rather than a lot of rules, conventions, strict object oriented paradigms, and so forth that prevent poor programmers from doing terrible things, the wild, wild west nature of little structure makes possible defining your own.  And when you know what you’re doing with that kind of freedom you can mold the language into something that suits your style and the way you think.  While the prevailing wisdom/complaint about Classic ASP is that it takes 9 lines of code to fetch a value from the database, like so:

Dim oConn, rsUsers
Set oConn = Server.CreateObject("ADODB.Connection")
oConn.Open "DRIVER={Microsoft Access Driver (*.mdb)}; DBQ=" & Server.MapPath("DB.mdb")
Set rsUsers = Server.CreateObject("ADODB.Recordset")
rsUsers.Open "SELECT firstName FROM tblUsers WHERE ID=4", oConn,1,3
Dim firstName : firstName = rsUsers("firstName")
Set rsUsers = nothingoConn.Close()
Set oConn = nothing

I find programming remarkably tolerable with some well crafted, low level extensions to the language, which makes my work look more like this:

Dim firstName : firstName = GetDatabaseField("tblUsers", "firstName", 4)

So-called “bottom up” programming is nothing new, but I seldom see it done well in the ASP code of others.  The intersection between people using such an obscure and primitive language and people able enough to lend real ingenuity to a programming environment appears to be pretty sparse.

But that’s just it.

That’s one of the things that I credit my current overall ability of web programming to: I cut my teeth on classic ASP when it was relevant and did some substantial projects in it, and needing to “roll my own” in a sparse programming environment as opposed to waiting for some .NET package to solve a problem for me has made me intimately familiar with the low level workings of browsers, databases and so on.  Its like training at altitude: make something work in unfavorable conditions, and you can really excel everywhere else.

So here’s to you, classic ASP.  I am a better programmer for your out-of-the-box crudeness, and accordingly you haven’t been that bad to work with anyway.

Michael Gerber, in his treatise on entrepreneurship The E-Myth [1], makes a firm point of the dangers of working in your business when you yourself are the entrepreneur trying to run and grow it (i.e. working on your business).  He makes a compelling case that the activities of one and the other are not only completely distinct, but that they are also virtually mutually exclusive.

I completely agree.

It was a watershed moment for me when I acknowledged for myself that am far more interested in being a consultant than building and running a consultancy, even though the the latter carries with it much more prestige.  I love the kind of consulting and application development that I do, and at the same time I have no interest in building a team of me-clones to do contract consulting work.   So when it comes to me as a free agent consultant, I am much more about working in my business than on my business, and Michael Gerber is right to say that I haven’t created a business so much as a job.

The reason this is interesting at all is because of the fun twist on the in-the-business/on-the-business dichotomy that I love to play with: for an application developer who is not afraid to get his/her hands dirty with the daily roles and work of a given business, there is opportunity to make massive improvements to how that work is done.  An example will make this clear.

During my one straight job out of school at MonsterCommerce I held a number of roles and one of them was manager of the custom programming department.  We were an e-commerce company selling an already spiffy, feature-loaded shopping cart software package, but that didn’t stop loads of our customers from wanting it to do more new and novel things.  So we had a custom programming department that would take feature requests, offer quotes for the work, and execute the jobs when opted for.  About 2-4 requests would come in per day.

The system I inherited for managing these leads and projects was a drawer of a few hanging folders, my predecessor’s email in-box, and a notebook or two of notes.  The notebook system, it turns out, scaled maybe for two weeks’ worth of leads before becoming cumbersome and impossible to manage without jobs and tasks slipping through the cracks.  By this firsthand experience of working in the business I knew things could be better, and with programming skills, a desire to learn web programming (new to me then), and a dash of confidence (arrogance? ) I set out to create the solution I knew I wanted.

It was fueled by a simple vision: whenever so-and-so called, I wanted to type their name in, see their job on my screen with the complete lowdown (what they wanted, the status of the job, and even when we last talked and what was said), and be able to talk intelligibly about their project within 10 seconds as if getting it done was the only thing on my mind.  (I think a lot of visions are fueled by frustration of doing something a few times when you know it could be so much better.)

Taking inspiration (and the design aesthetic) from our own shopping cart software, I learned how to program web applications[2] and design databases, and built my dream system one weekend at a time.  It sat there, hosted humbly on the floor within the computer in my bedroom, during a time when each subsequent week a little more of my job was managed or automated by it.

After six weekends of development (and the interim six weeks of real-world use, testing, and tweaking), I was ready to show off my baby to the rest of the company.  It was well received by all the parties it touched upon: billing, sales, management, and my team of programmers, and getting adoption was quick and painless.  (The greatest honor was when the Design and SEO department heads both requested a similar system: I quickly forked off versions to suit both.  The second greatest honor was hearing that it wasn’t until 2009 until these systems were retired, fully 3 years after I left the company.)

Building something that good was made easy (almost trivial, it felt) because I was making it for me to solve my own day-to-day problems.  When my day-to-day usage revealed something that sucked I would simply fix it that night at home, and have a better system the next day.  I had bridged the creator/user gap.

Not only were the systems nice and made a manager’s job easier, it made the departments better.  Communication, coordination, follow through, professionalism and the bottom line all benefited.  It was the stuff of systematizing things that Micheal Gerber would classify as working on the business, and doing so happened because I was steeped a little while working in the business.

This is completely unconventional.  Software development talent seldom experiences the day-to-day work of the people for whom they create software for, yet what if that experience is a shortcut to making a really great system?  Though unorthodox, time spent by a developer actually doing a job for which he/she is to make a software system for may pay out overall in time saved trying to otherwise imagine, describe and communicate the software needs.   Any additional unimagined solutions/shortcuts/innovations devised by the developer-turned-worker are a pleasant bonus.  Furthermore it makes nice protection from rough or ugly spots in an application: if a developer is saddled with using his/her own creation (even if for a little while), they will be apt to smooth over and tidy up such unflattering features.

It may be a loophole to the notion that if you’re working in the business you can’t possibly working on it: insofar as software systems are concerned, at least, a person working the job who is able to design systems to make it easier is leveraging the former to help the latter.

Notes:

[1] It’s been 4 years since I read it, so please pardon any haziness in my recollection of it.

[2] This is the root of my [still persistent] fondness for Classic ASP, an arguably terrible and woefully outdated server side web language.  There’s always something special about your first.