Doing It Right
I’ve been building web sites for some twelve years now. And I love what I do: using code to express an idea is a task that I approach, every day, with a sense of humility and honour.
But if there’s one thing I really hate about being a developer, it’s that circumstance forces me to be less good at my job than I’d like.
This job description, posted by a Denver-based Web development shop named CrowdFavorite, kind of set me off. I can’t speak to whether their actual working environment matches the description of their job posting, but it made me confront the uncomfortable facts of my own career.
CrowdFavorite’s hiring ethos appears to be based around the notion that quality matters most. They want to hire developers who strive to create “a truly elegant finished product”.
Who the heck wouldn’t want to do that?
But there’s an unmentioned tension in that post. It comes from the time-worn engineering truism, that goes something like this: “On time, on budget, done right. Pick two.”
In my career, as a freelancer and as an employee for other companies, I’m overwhelmingly pushed to accept the first two as immutable, with the third as a variable. It’s never a question of “doing it right”; instead, it’s getting it delivered by a certain date, with an acceptable level of quality.
“Doing it right” comes with a great number of customer-unfriendly terms. You can’t claim how long it will take to do it right, because programming is complicated, and optimistic specifications might need to be re-written. You can’t claim that it will cost a certain set amount, because you’re developing a feature that’s never been done in this way before, and like basic R&D, it can’t be rushed.
So when you put your emphasis on “doing it right”, you inspire images of a bucolic land of un-rushed timetables, laissez-faire development and a “whenever-you’re-happy-with-it” management style.
I’m blue-skying here, but let me paint you a portrait of a developer who doesn’t feel like he or she needs to focus on anything but delivering top-notch user experiences. That person would spend hours gazing out the window, deep in thought. There’d be some chatting with colleagues, some whiteboarding, and some coding sessions. Coding would be an activity of long silences punctuated by the occasional patter of keystrokes. The results of their work — ideally arrived at through some consensus with other stakeholders — would be deeply personal, defended vigourously, and delivered in an iron-clad quality guarantee.
That’s not my life. As long as I’ve been doing this work, I’ve been frantically hammering away at my keyboard, planning while I code. I make stupid mistakes and hurriedly scamper back to correct them. I’m pulled in many different directions: by management, clients, the too-few hours of the day, and the constant, over-arching need to produce, ASAP. The results are makeshift, bugs are normal, and I’m often battling on two fronts: to both fix what I’ve broken, and to make the new stuff.
These are two ends of a spectrum. Surely even CrowdFavorite will nudge their developers to hit certain milestones, and surely I need to be better at pushing back on deadlines (while simultaneously extending the job, and the paycheque… argh!).
It seems like a fantasy. To accomplish it, the developer needs to be protected, at almost any cost, from the pressures of the inevitable money-holders. I don’t know how that’s possible, to be frank.
Again, I don’t want to make any claims about this job posting, but it sure feels like a beautiful tale, rather than reality.
But if given the choice between my end and theirs… oh boy, I would love to be there. So let’s all take a deep breath, step back and figure out how we can turn our reality — even just a tiny bit — into CrowdFavorite’s happy fantasy.