The Agency Developer
If you enjoy semantics-fueled tête-à-têtes, then I highly recommend The Atlantic article Programmers Should Not Call Themselves Engineers, and a response from Wired entitled Programmers, Let’s Earn the Right to Be Called Engineers. They both go on about accountability and burdens. Node is mentioned. It’s very interesting.
And I’ve come to realize that I don’t really consider myself a Programmer or an Engineer. I’ve always preferred the term Developer (Web Developer if you’re nasty). As I’ve grown in this industry and become more and more an agency man, that is, spending the majority of my career working for marketing agencies, I’ve come to have a special relationship with the term and all that it means to me.
But first, a quick sidetrack to look at what I think it isn’t.
A while back I toured the amazing Atlanta Tech Village, which included a look at one of the many companies taking up residence there. We walked in to a company of maybe 15 people and a found ourselves straddling the border between two warring factions. On one side, a bright room, with windows open and ears mostly un-headphoned, sat the marketers, project managers, and leadership. On the other side, in total darkness on a lovely summer day, sat the be-hoodied and silent programmers, dutifully tackling tickets and feature requests.
I’ve been writing code for about 12 years now. And it’s always with the lights on. I wear headphones, though usually with one ear uncovered so no one has to yell to get my attention. And look, no ill-will towards those guys (they were all guys) coding away in the dark. They build products and I know the focus it takes to hold something that massive and complex in your head while working on it.
But if you present yourself as someone who cannot be bothered, you won’t be. You won’t be invited to strategy meetings, or involved in client pitches, or pulled away from your daily work to secretly build something amazing.
It is my ardent hope to learn how to hire people that will gun for my job. So it occurred to me to simply write down what one would have to do in order to unseat me. And then you’ll know what being an agency developer means to me.
Present yourself as someone who can solve problems.
In his amazing and totally dead-I-can’t-find-clips-anywhere online show, Ze Frank laid out everything you should look for in a web developer. On problem solving he recommended:
Hand the developer a proposal and ask them to give an estimate. First, I’ll show you a bad response:
“That’ll be around 8 hours. That’s a little tricky. That’d be around 20.”
Now I’ll show you the correct response:
“Hmm, [points on the sheet without looking] that can’t be done.”
This is still something I constantly struggle with, so maybe it’s bred into us. Just like if you asked me to type Stamp Coverflow I would inevitably type Stack Overflow…
Developers are faced with problems near constantly, and almost never have insight into client wishes and budget constraints, so it is very easy to want to point out problems and balk at difficult requests. But please, do the hard thing instead. Take a moment, consider the issue at hand, and try to consider solutions instead of just bringing up problems. Later, when the meeting is over, talk to your boss if you have a timing or staffing issue that needs to be worked out in order to make a solution possible.
(Jeremy Heilpern goes into this more in his article, aptly titled, On Solving Problems.)
Learn how to speak about your work to people that don’t understand it.
Inevitably a developer will be asked to build something too quickly, or explain why something is behind, or why a certain technology is needed over another. When that time comes, I recommend speaking to the interests of the person making the request instead of technical issues.
For example, I chose Laravel as the backend of a project I’m working on to support a mobile app. Laravel is quite new, and while it is quickly gaining clout it is largely unknown outside of developer circles. And I chose it for a large, scalable project despite having never used it before. I chose it because it’s beautiful, the community is amazing, I find the code really easy and fun to dig into, and I appreciate that it runs along PHP’s bleeding edge. Now I could tell my boss all about dependency injection, the eloquent ORM, the built-in queue management, the easy integration with unit testing, and so on.
But… why? Why would he care? And why would I expect him to? I would no sooner give him those reasons as I would discuss PHP’s fight to be considered a legitimate programming language on a first date… or to my wife of 3 years. My boss deals with business interests, so I provided him with (totally true) business reasons. For example: stable releases will be supported for several years, it leads to a far smaller codebase that we have to support, we have to worry far less about standard stuff that all apps do (authenticate, validate, etc), and the community is thriving and helpful.
Done. Sold. Next problem.
Be client ready.
If you are gunning for my job, this is probably where I’ll stump you. We have a great team at Morrison, but at previous jobs it seemed a mark of pride that a developer couldn’t be brought into client meetings. And I’m not talking about attire, anyone can change clothes. I’m talking about the way one speaks, carries themselves, interact with others, and contributes to conversations.
This point is so important, it gets its own list!
- Bring value to conversations you’re brought in on. Sometimes that means being silent, which is totally fine. But if you speak, have something meaningful to say, or a useful question.
- Don’t fight your coworkers in meetings. Sometimes the person running the meeting will agree to a difficult timeline, or a weird feature. Maybe mention that you want to talk to them about that later, or recommend another way to solve the problem. But undermining your coworker in front of a group will accomplish nothing but making sure someone else fills your seat next time.
- Be prepared to patiently teach the client how to use the thing you made for them. Remember, nothing about what you do is obvious. Treat their lack of knowledge with understanding and their silly questions with civility.
- And finally: sell yourself. You possess a deep, in-demand skill set. You are capable of things that your client cannot do alone. Bring your boss ideas for clients, and then be prepared to pitch it to your client as well.
I don’t pretend to be the best developer in the world. I believe that I have a strong, well-rounded skill set that is well suited to the constantly changing and challenging types of work done by marketing agencies. But I have to remind myself to focus on solutions, I have to remind myself to be kind to coworkers and clients that don’t understand or care about the way I get things done. I have to be mindful that, as much as I might not like it, short timelines can be necessary and late nights can be a feature instead of a bug.
But I’m in a position to work on strategy, to recommend new work to clients, to architect complex digital solutions to business problems. And these are things I want every other agency developer able to do as well.
