Programmer for Hire

A few weeks ago I had the opportunity to have a spirited discussion via email with a fellow just about to graduate with a CS degree, centered around a few themes here on Programmer for Hire.  Here are excerpts from the email that got us started:

Hey John

I’ve read nine or ten of your essays in about an hour or so time frame, and I find myself wondering “Hmm.. I’m about to graduate college, and this fellow’s got it in his pocket. Seems to do well for himself, et cetera…” but then after I finished reading the last two, “The Free Day” and “What Happens if I Get Hit by a Bus?“, something bothers me, and I can’t really put it into the most perfect set of words, but I’ll try to communicate/ask-about my thought(s). It may read like an “attack” on you… and that might be a fair assessment, but that is not the intention. My goal was to show how your actions perpetuate a mentality that would be difficult to break out of, not to mention degrade the field as it is already.

I’ve noticed that in the field, there are what appears to be hidden .. guidelines (rules, codes, mores?, not sure what word to put here).. that revolve around the ego. Is this true, or is it more an attribute most seen in the “lone programmer” types? I recall reading you “walked out on air” [The Free Day] as though you ‘saved the day’ or something, as if you were the man of the hour, or day, as it were. Then, in the second essay discussing ideas for your hypothetical replacement, the new person should be able to understand your work, because “my code is quite beautiful and well organized, with perfectly uniform indentation and formatting, completely consistent conventions, and immaculately well factored” in the space of just one day.

First off, from my perspective, I don’t even need to synthesize anything from the preceding paragraph. I think it speaks with enough volume to make its own point. Maybe I missed a day in class that covered ego and “why it’s important to have to succeed in this field” because if so, man, a) I’m fucked, but more importantly b) the industry is fucked. If you can think about it [don’t want your ego to get in the way here], consider this: you are a tool. It sucks not being on top. Even Zuckerburg isn’t on top. Sure, he’s got numbers to play with and spout around, but in reality. he is a tool. His job is to make other people richer. Sure, you’re probably not at his level in the field, but the idea of you make other people richer still applies. A tool has to be bought, so there is the initial investment [see that key word here?], but its price is paid off [usually] by using it to create things that cost more for those the tool’s services are required, in order for it to be sold for a profit. [hammer -> house -> homeowner]. Your job as a tool is no different. Maybe that’s why you and others in similar environments look to other ways of measuring success, ie: “I had 40 clients last year!” or “My app was downloaded 3400 times last night!”, et cetera.

…  I am not saying you will cause a war to occur… but then again, aren’t you already in one? You purport yourself to be a one-man army, capable of reducing the vision into reality. You may very well be able to do such things [it seems so], but does that mean everyone should then become a one-man army?  …

Alas, I think soon it won’t matter. As I wrap up my studies, I keep finding evidence that I don’t like the field I’ve chosen, even though I’ve been told I’m pretty good. I subsequently tell those who tell me that, that they are incorrect; they are comparing me to their skill in the art, not the greats. Of course the greats don’t become great by staying behind the scenes. They need their name out there, in front of people, part of some discussion or controversy, et cetera. As the days go by, the counter measuring my disgust increments too.

…

PS: I don’t want you to stop cold-turkey. In fact, continue what you do. This is just some new guy to the real-world trying to understand it [even if from a more… aggressive and accusatory standpoint]. If you read it all, and want to kill me.. or whatever… I do apologize. I am a new-born programmer… but that doesn’t mean I don’t have convictions.

This gave me real pause for thought.  If my tales of programming are leaving members of the next generation of programmers with misgivings and distaste about the field, I’m both surprised and keen to make amends.

Here was my reply:

Hey ____!

First off to be clear: I don’t want to kill you.  On the contrary, I give you serious props and respect for thinking deep on all this enough to question my words and raise some real valid points of contention.  I appreciate your earnest curiosity and willingness to call (what I would label) tentative bullshit on some of the ideas I share on the blog.

So what I’m hearing in your words is a healthy concern that programming (or at least the freelance market of it) is being purported as a massive bout of egos: with both constructive elements (e.g. how bolstered sense of self importance fosters serious productivity) and destructive elements (e.g. if you’re not good enough to follow MY code, you’re fired).

If you’re open to it, I’d like to offer you a different perspective which may help to decrement your disgust counter about your contemplated field as you round out the current phase of your education.

Consider programming as a craft, and you and I as craftsmen.

As craftsmen we may choose to take serious pride in our art and commit ourselves to deepening our practice and grow, learn, and improve in an ongoing basis.  We may also choose to resist our craft while staying in it: complain about it, insist that the other guy’s code is shit, and maintain a tendency to make excuses for difficulties encountered, lack of results, broken promises, etc.  (Since it is pretty well agreed upon that programming is a rich, complicated, and on the whole difficult practice, we have a lot to draw from when making excuses.)

My ethos in my craft is to be the best darn programmer for hire I can be, and to hold myself to a very high standard so that I’m worth every penny to the people who hire me (that entails making big promises, following through with high integrity, and completely owning my fuck ups when the occur).  My aim in blogging is to spread that sort of pride (and the attendant benefit, i.e. charging a lot and doing folks a lot of good for it) to my fellow programmer, and at the same time advise the hiring world that you don’t have to settle for shitty development talent, which the business world by and large seems to think it must (just ask a typical project manager about the frequency of excuses, lack of results, and broken promises they’ve encountered).

Where ego gets nasty (and is apt to rightly increment your disgust) is when it is applied with hypocrisy: when I’m a bumbler but should be tolerated ‘cuz I’ve got lots of really great excuses, while everyone else who missteps is shit and should be fired.

That, I agree, just fucks the industry with a warped terrain of self-deluded talent and hapless hire-ers who don’t know who to trust.

The world in general works better when people (meaning ourselves and the folks around us) take responsibility for results happening, pursue excellence, have pride in doing great work, honor promises, and decline to indulge in excuses, blaming others, and complaints.  (Please look for yourself to see if the preceding sentence sounds about right to you.)  Consider that our craft is no exception.

Side note about being a tool: no one needs to be bummed about being one.  With a deliberate choice of language you can flip the notion of “being a tool” into “being of service to something or someone, which gives purpose”.  Most everyone who earns a living is a tool by the definition you invoke.  Consider that it’s actually not a problem, especially if you enjoy and have pride in what you’re doing.  Success is in the eye of the beholder, and what works well for me in gauging success is the quality of life that my craft affords me to live.

So you’ve got the opportunity to play in this craft.  If you focus your attention on all the prick waving and caustic competitiveness, I reckon it doesn’t look that appealing, especially since you’re apt to fall into that game by the mere act of focusing on it.  (It’s analogous to “keeping up with the Jones’s”: obsess over whatever’s parked in their driveway and you’ve got a problem, ignore the Jones’s and you’re free to do your own thing.)

There is an alternative, and that is to transcend the whole darn thing.  I’m actually not at war with anyone, and you don’t need to be either.  I learn a lot from the greats (my heroes who contribute massively to our craft), pay it forward by contributing to others, and otherwise just do my own thing in a personal pursuit of what to me is excellence.

There’s one last thing I want to leave you with about the field you’ve chosen but are having second thoughts about: it’s actually pretty sweet.  My wife and I are–no joke–moving out of our apartment in two weeks to go on a roughly 15 month world tour.  Everyone says how lucky we are, and though I resist that a little because it’s more a deliberate choice and creation (we didn’t win the lottery), there is truth in how blessed I am to have a job where I can work anywhere in the world with just a laptop and wi-fi.  To me that’s awesome, that’s that quality of life thing I mentioned.  No one’s stats are a threat to that.

I hope at least some of the above is useful to you, and know that I appreciate you sharing your perspective.  As you might guess from the tagline of my blog I’m fascinated by the culture of programmers and how we view and act in the field–the good, bad, and ugly.  So if you’d like I’d be happy to continue this spirited conversation with you on the phone some time–my number is (720) 621-0600.  In any event, all the best as you finish your undergrad studies, and in whatever path you pick for your career.

He and I had one more email volley, and to his follow up remark,

“…you do bring up some food for thought. I’ve thought about the craftsmanship aspect, but I can see a little ego in there still — however, I think with good practice, it can be useful, but held in check.”

I had this to say, which I think sums it up for all of us programmers:

When it comes to ego: it’s up to you to manage it in whatever manner works well for you.  At the end of the day you’ll either come of as an insufferable cock-jockey, a complete delight to work with, or somewhere in between.  Since that reality holds true for you and everyone else, there’s a lot of great incentive and room for folks keeping their egos in check and having our craft be more of a peaceful playground.  It’s the notion that I get to control my part of the equation which makes me pretty optimistic about the state of our field–your mileage may vary, but try that on.

Last month a good friend of mine, Chris Kissner of ProCntr, invited me to give video blogging a whirl.

Chris has all the stuff for a video session: lights, cameras, backdrops, reflectors, you name it.  He even gave me a little foundation makeup to look my best on camera.

We riffed for about 2 hours on camera about freelancing, web development, client relations, coaching, projects, nerd culture, my craft, and more.  Chris played the interviewer and efficiently probed my brain on the very kinds of thoughts usually featured in written form here on Programmer for Hire, and for the first time ever captured them on video.

The end result is quite nice.  Chris has done a good job of tidying up, editing down, and slicing the footage up into self-contained nuggets.

The first clip is below, in which we talk about transcending the role of web technician and getting into the realm of massive gains realized by strong communication between contractor and client.

Enjoy!

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:

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.

I recently had a good sense to add this new boilerplate section to my standard project contracts:

3.5 RIGHT TO DEMAND SATISFACTION

Acceptance of this agreement includes the right to demand satisfaction for all described features, no more, no less.  I’m on the hook to complete all the described features to the point that you love it, and you get to demand satisfaction to that extent.  So do it.  If you’re not happy, and you haven’t exercised this clause, you’re technically in breach of this agreement.  Just sayin’.

In my years of experience I have never been burned putting myself on the hook called “my work is not done until you love it” , so I realized that I may as well get the benefit of advertising as much up front.

I don’t know that this sort of clause exists anywhere else in my industry.  Flippant language aside (which in my estimation is rad: if that sort of playfulness backed up solid performance turns you off, you’re not my client anyway), I think there’s a general fear about having to appease some fictional, nightmare client who is endlessly demanding.  In my experience, when it comes to my world of web programming, they don’t exist¹.  Oh sure, there’s always room to want more features, or a cheaper price, but that’s not what what’s on the table here.

This here is a promise to do great with all of the [meticulously outlined] features within the scope of work at hand.  Software development is generally a complex endeavor so I think the average bear understandably shies away from such a tall promise.  Fair enough.  I embrace it.  It keeps me honest and fosters a healthy pride in my craft, and if I just bring my art to it using my full facility with leading edge technologies and tricks, I don’t have to worry about falling short.

So I don’t fall short.  If my first attempt isn’t loved by my client, they tell me and I tweak accordingly.  No fuss, no muss².

That’s the second beauty of stating up front the right to demand satisfaction: it creates a conversational dynamic between my client and I that deliberately CALLS FOR that kind of feedback.  We become partners in the endeavor to create software that perfectly suits, and they have a role to play called “speak up if you don’t love it.”  When the invitation to do that is clear and on the table it is easy and fun to exercise, and moreover doesn’t get compromised by a desire to be polite.

Notes:

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.

A few weeks ago I was on a conference call with a client talking about a new, expanded direction they were mapping out for their e-commerce.  The scope of the project was well within my reach to execute quickly and thoroughly, but there were good & valid concerns expressed over me being the keeper of the system as a one-man show.  After all, it would not work if a problem arose that only I was trained to address at a time when I was, say, gallivanting about in Panama: it would be irresponsible to structure a major part of their business to be vulnerable to failures that arise with poor timing.

As I’ve mentioned before on this blog, I’m a big fan of the benefits made possible by being a team of one.  I also really like the agility and flexibility afforded by being a solo act in the business aspect of my trade.  So when it was asked if I would hire and train up others to make possible a 24/7 manning and support of the project, I saw it fit to propose a re-framing of the situation.

This particular client is big.  The company has their own dedicated IT department complete with plenty of smart folks who are able to build, run and maintain complex systems.  They are also savvy about outsourcing: they know how to keep their own internal team smoothly handling internal operations by calling in outside talent to help with big initiatives when they come down the pike (which is why were having the conversation at all).

Rather than operate as a separate team on this project, I reasoned, why not have my contribution to the project be an augmentation of their existing resources?  Given they already have an in-house team that works on other things which integrate tightly with their e-commerce, I could do the heavy lifting for the project (that is to say: design and build it to everyone’s delight, and see it through to a successful launch), and then take necessary steps to leave their internal team empowered to own and maintain it with minimal effort.

It’s like building a building.  The work of the architect and the construction crew are distinct from that of the maintenance team and cleaners.  The better job that the former does enables an easier ongoing job for the latter.  In our case of software development I’ll refer to these two parties succinctly as builder and maintainer.

Characterizing a Successful Arrangement

So what are the characteristics that should probably be in place for such a collaborative hand off work to everyone’s delight?  There are a few things I can think of (this list is no doubt exhaustive, if you can name one I missed please leave it in a comment):

• The system handed over by the builder should as clean and intuitive as possible. Clean software architecture rules the day here, and any lingering patch-job hacks represent a great disservice of future burdens to the maintainer.
• The builder should train the maintainer. Without a doubt, the curse of knowledge can easily give the builder a comforting illusion that it should be easy for the maintainer to spot and fix problems the arise.  Rather, a maintainer should be left confident that they know how to navigate the structure of the code.  When they have reached that level it should be their call to make, not for the builder to assume.
• The builder should be accessible to the maintainer over time. Not 24/7 for hot fixes (that would defeat the purpose of handing off to a maintainer), but as an adviser for deeper, more long term issues including building further on the system.
• The maintainer should be technically qualified for the role. They needn’t be as skilled with the code as the builder (after all, it’s easier to maintain a well built system than to build it well in the first place), but they should be able to track down and fix minor bugs in addition to more regular maintenance.
• There should be general camaraderie and a shared commitment as a team between builder and maintainer. While hardest to quantify this is perhaps the most important: it’s a problem waiting to happen if a builder hands off the project with any air of “it’s your problem now”.  When the builder is oriented as a long term partner, his or her priorities are well-aligned with the project as  a whole: “I will do it right because I am ultimately accountable for its performance”.  The desire to avoid saddling the maintainer with a problem is a powerful motivation to set them up well.

These characteristics represent a chunk of overhead of the Augmenting a Team route, relative to using a separate one.  When handing off a project to a separate team, that team is free to manage long-term maintainability internally, however they deem appropriate.

What’s interesting about is that is how, in the scramble to get it launched, notions of longer term maintainability can (and do) fall by the wayside.  When a builder steps in to augment a team on a project, the above characteristics form a nice recipe for clean execution of a project; one that is mindful of both the initial work and long term maintainability.  It’s like having people over for dinner: you’re more likely to clean up your place out of courtesy to your guests.  A builder who knows that a maintenance team will be looking at and learning their code soon will do more to be proud of such a close inspection.

In my experience, some of the formality of programming for hire seems to precipitate an unfortunate reliance on email for communication in lieu of picking up the phone, and this goes both ways: client to programmer, and programmer to client.  There are a number of reasons for this that I can see:

• The stereotype that programmers are anti-social and/or need to concentrate (a client might think “maybe I shouldn’t call them and interrupt their programming mojo”).
• The reality that programmers are anti-social and/or need to concentrate (a programmer might think “if I call them we’ll get wrapped up in all kinds of winding dialog about out-of-scope feature requests and what-ifs”).
• An unclear working arrangement for that kind of time spent (does phoning up the programmer hotline rack up billable hours?).
• A perceived notion that an email, being less intrusive, is a better way to respect the other party’s time.

These are all valid reasons, but the downside of being stuck with them is the [largely hidden] downside that lurks in relying on email communication for such a thing as software development.

Software development is complex.

It’s not necessarily hard, but it’s complex: there are many small parts that come together to make up the finished product.  The process of creating it is therefore is ripe for ambiguities, misunderstandings, and varied interpretations of the same stated intentions.

The antidote?  Clear and fluid communication.  Communication that does not require formalities like a scheduled meeting with 2 weeks lead time.  My ideal is being able to pick up the phone, get my client up to speed on what’s going on, and answer whatever questions are on the table.  Five minutes is par for the process, and when it really works we end the call feeling like genuine collaborators building something great, clear that our visions are aligned and we’re on track.

By email that kind of satisfaction just isn’t possible.  If I have a question, there’s a decent chance that what I’m asking won’t be fully addressed by the email answer I get back, and an even better chance that I’ll have a follow up question precipitated by that answer.  The minutes both me and the client have spent typing up our correspondence quickly passes the five minute mark, and the back and forth doesn’t do nearly as much to bolster a sense of team, or confidence that all is progressing smoothly.

That’s why I like to encourage that kind of accessibility: I want my clients to call me up when they’ve got something on their mind pertinent to the project, and I request of them license to do the same.  I have yet to have a client abuse the privilege or even come close to doing anything that could be called wasting my time.  When I come across a design decision I hadn’t considered and don’t know enough to pick what will be best for the business, I love calling my client and getting them in on the scenario.  It gets them interested and involved in new opportunities, and lets them be more at the helm of getting exactly the end product they want.

This pertains to more-or-less corporate development projects, where projects are invariably rooted in a real bottom line intention.

If your developers aren’t hip to the surrounding business lingo, or don’t have time (or inclination) to learn the bigger picture  (like which kind of customers are going to be using it, the anticipated ROI, or what the customer support team really needs, etc.), make sure you’ve got a translator to bridge the gap.

On one side, a good translator will ensure that the business brains devising the project aren’t overlooking some great opportunities that tech could offer to solve the problem, and that they aren’t asking for what turns out to be a technical nightmare for only a minor gain.

On the tech side a translator will make sure the programmers don’t get carried away with the “cool factor” (tech for the sake of tech), and that instead what they’re churning out is a real fit for what’s intended.

The net result on both sides is that a good translator will keep a project on track, true to it’s original need, and ensure that the technology being employed is a good fit for the problem at hand.