Home > Essays > Programmer Resistance

Programmer Resistance

A while back I interviewed a longtime client on how he viewed working with me: I was looking to get a real, introspective look on what works about my style of service, what’s lacking, why hire me at all, and so on.

I got a number of pearls out of the experience, but one in particular I’d never heard or even considered before: “What’s really nice is that you put up no resistance.”  Eh?  “Say more about that”, I replied.

Paraphrasing, he said that when there’s a problem or a snag I just go with the flow of whatever is deemed important and I’m game to just work any which way towards a solution.  Whenever faced with “hey, this isn’t working”, I’ll quickly improv and alternative and it’s NOT A BIG DEAL.  No resistance.

What a cool distinction.

For sure, it’s common in my field for formality and ceremony to get in the way of a quick, pragmatic solution to a problem (this is, after all, an industry that derives a lot of self-importance out of months long dev cycles, rigid road maps to follow, rigorous testing, and the occasional 370 million dollar error).  So if a programmer assumes the demeanor that doing X or changing Y will be a big deal and is likely to take loads of time or apt to cause tons of complications, their expertise and warning generally needs to be heeded, at least by non-programmers.  (This is not unlike the futility of arguing with your mechanic over the state of your car’s transmission, when you are not a mechanic.)

Being a low resistance programmer requires a combination of both mastery over the domain (necessary to responsibly perform a given task, correctly and without ill side-effects) and the discipline to not indulge in a story of exaggerated burden (which can be gamed for inflated pay and longer time lines).  So when it comes to the relative merits of programmers, low resistance is of course favorable, but only given comparably good end results.  Two programmers might share the “can do, no problem” attitude up front, but if one of them took 3 times longer than anticipated or made a quick mess of things, that’s a matter of being naive, not willing and able.

Every situation is different, of course (some things should be a quick fix, and others genuinely are a big deal), but over time I think it’s possible for a non-programmer to gauge what kind of programmer they are working with.  Say you have a programmer that you rely for keeping critical parts of your business operations running smoothly.  If it’s a pleasure to bring issues to their attention because you typically leave the interaction with a sense of peace and that all is well in the world, you probably have a programmer who makes your issues theirs, and then makes small and tidy work of it.  If you have someone you hate to bring problems too because it makes you feel like life is generally a complicated mess, then you probably have a programmer who’s more invested in telling you how hard their work is than actually tending to what you need them for.



Next:


This is Programmer for Hire, a series of essays and explorations on the art of being a great programmer doing on-demand custom software development.

Looking to up your game as a programmer for hire? You can get one-on-one coaching from the author of this blog.
Learn more.

Looking for help and advice on how to get your programming project done? The author can help you as well.
Learn more.




  1. April 17th, 2012 at 16:13 | #1

    Interesting topic! I have this type of relationship with one of my clients – I think he sees me as “The Go-To Guy” for techie stuff, and generally I can solve any issues we meet on the way to finishing whatever the project is. He gives me leeway in finding solutions, and I implement the best one I find: win-win. He’s also the client who pays the invoice within 30 minutes of me emailing it off – I love working with these kinds of people and I think there’s a direct relationship between the good communications and his approach to business.

    The problem with this situation, though, is the potential for getting bogged down in solutions that turn out to be not quite as simple as anticipated. Suddenly the 1 hour fix turns into a 4 or 5 hour hackathon. You have to be wary of saying “I’ve got this” and jumping in feet first – you could end up swallowing a couple hours of lost income in order to keep a client. This is all very situational and dependent on the client, your communication skills and the contract.

    Personally, I find that I really need to watch myself, because I’m an optimist at heart!

  1. No trackbacks yet.