5 Things I’m Learning Going from Agency Work to Product Work
How I went from doing advertising agency campaigns to product work at BuzzFeed.
Before joining BuzzFeed’s Tech team about three months ago as a software engineer, I was a full-stack web developer at an advertising agency.
I was not an account manager that would interface with the client, so this story isn’t going to be about agency life in general. I’m here to tell you about how I grew as a developer, what made me want to switch from agency work to product work, and what challenges I’m facing — and conquering! — as I transition from what I used to know to what I’m learning now.
1. Campaigns Die, Products Are Forever*
*Kinda.
Simply put: a campaign is just a centralized effort by a brand or client to push a specific product or event. When there was a microsite or activation that required a technical connection to a social platform API, the accounts teams would call upon the Friendly Neighborhood Tech Team® to build it, if my old agency didn’t already consult the brand’s agency of record, another dev shop, or the client’s in-house tech.
Work like this was frequent and varied. At any given time, I would probably be working on at least two projects, and later on, overseeing a third, maybe even planning a fourth. Although the variety was nice, often this variety was typically in the form of the creative design. When the dev team would build Something New And Cool™ for one account, other account teams would pitch a version of it to their client, and we would simply rebuild it with some small functionality tweaks and design updates.
There is a lot of variety in agency work because campaigns are relatively short-lived. I have had a campaign literally last one week: we had spent at least 80 hours on it, and that was just development time, not all of the days and weeks prior to tech team hand-off that included brainstorming and creative design. Development was quick and scrappy to get it done on time (I’ll talk more about speed later on).
At BuzzFeed, I’m on the Ad Experience team. We have several products we implement on our various, larger services in order to serve BuzzFeed users good advertisements. The team has reusable components and services that we’re putting in place to be able to work seamlessly with the other teams within the BuzzFeed Tech. The product(s) usually live “forever” for us to iterate on it (not literally forever, but my colleague Arielle has an informative article on the product lifecycle).
As the team iterates, I find myself going back and thinking about optimizing my code or how to make my logic “future-proof” should some feature need to be added to this section in the future. I never really got to do this in practice in the agency world. I could always outline or discuss how I would have done things better in a post mortem for a campaign — sometimes doing so helped for a re-implementation of that campaign under a different guise, but it never was truly improved.
This brings me to #2:
2. Your Code Can’t Be Just For You
As someone who has recently joined BuzzFeed Tech, there’s a lot of existing code: I repeat, a lot… a monolith, if you will. It took me my first couple of weeks just to get setup and familiar with the ins and outs of the code and the deployment process.
At the agency, because I was usually the singular developer or principal architect on a project, I knew all of the project’s ins and outs, its quirks and shortcuts. Comments were mostly just pseudocode and some occasionally-cryptic reminders (or TODOs frozen in time; more on that later). Sure, I had naming conventions, and the team had some coding style choices in order to keep things consistent and readable, but there was never truly an outlined coding style guide at the agency. I would occasionally have another developer supporting my project, but the second developer was never for anything so functionally changing about the project, simply bug fixes or tweaks that conformed to whatever code style and architecture I had already put in place.
Despite my team at BuzzFeed being approximately 12 people, there is also the aspect of my team that touches other services within the tech organization. It will never be just me looking at the code anymore. Good documentation, comments, and a consistent coding style guide are part of my transition over to working with a large team (even if I don’t agree with some of the conventions… I think leading commas are great). For example, in BuzzFeed Tech, there is a library of setup docs, write-ups on why our systems are built in certain ways, lists of helpful links, etc. We have an ongoing guide titled The BuzzFeed Guide to Computer & Software Systems that is actively being written. It explains our underlying software and infrastructure so everyone in the organization is on the same page.
In addition, I actually have regular code reviews now. Our pull requests are required to have at least one peer review whenever before we move onto testing and merging. These reviews are helping me learn, even with the smallest of updates and commits. There was sometimes light code review at the agency, but it was mostly done post mortem in order to “do it better next time.”
Speaking of getting it done… (Look at that segue!)
3. Getting It Done vs. Doing It The Right Way
Speed is everything at an agency. Getting things done in the shortest amount of time to save the client money and to get things out the door quickly is necessary to move on to the next project. It’s not to say that quality isn’t valued at the agency or speed isn’t valued here at BuzzFeed Tech, but there is a subtle difference between speed and agility.
There were many times I would have an engineering problem at the agency where I would continue to say to myself, “There has to be a better way.” I could figure out a creative solution, but when you work for a client, your project is then put into a box of technical constraints. The way you believe is the best way to execute the project may not allowed by those constraints. I had to be scrappy and get creative in some of my problem solving to get around some of the requirements of various campaigns; other times, I would have to just force it and try not to be grossed out by whatever blasphemous jargon of digital text I considered code. If it worked and got the job done, it was usually fine.
I always did my best to optimize and do things The Right Way, but doing so also may not have been in the best interest of time. I could have a proper solution for an aspect of the project, but executing my solution could be just out of reach in terms of how fast I could implement it, especially while there were other aspects of the project to work on. That was the hardest part: sacrificing one part of the project for another or even the ability to finish the project on time and within the scope of the campaign.
In Product World, you have the ability to come back to something later, so coding it fast and loose the first time is not so jarring, especially if we do want to quickly deliver new features and test them. On top of that, while working at the agency, some subtle performance things on the user-end could be sacrificed for a campaign. A product is continuously visited (harkening back to the lifespan of a campaign versus product) so engineering things The Right Way is always in our best interest, and — over time — better solutions will be found as data is gathered, users share their experiences, software engineers iterate, and technology progresses. The ability to ship quickly but continue to improve is what “agile” software development is; perhaps that’s why it became such a tech buzzword.
4. Jack of all Trades to Master of One**
** Well, not just one, but I wear significantly fewer hats now.
As one of the first developers of the agency I joined, it was a department that needed to grow and was very rough around the edges for some time. As such, I had to be flexible and wear many hats: I could be a UI designer, UX researcher, front-end or back-end developer, infrastructure and operations, QA Engineer, database admin, manager, etc. I had a perspective on many aspects of web development, but usually I learned just enough to get by and get the job done. As the agency grew, others were hired to fill these roles, but everyone still wore each other’s hats for coverage in case someone got sick or was out of the office.
An analogous thing happened with web technologies and web platforms the campaigns would interface with. The agency had many clients with many different requirements. Maybe the client had a proprietary CMS that the agency devs had to learn and interface with; another might’ve allowed us only jQuery; perhaps there was a Twitter-feed aggregator or another third-party vendor that had an API we needed to consume and integrate with the campaign.
In terms of a “web stack,” the agency dev team did not really define one; we tried to stick with some of our tried and true boilerplates. Other times if a project would benefit from the features of a particular framework, like Angular or React, we would utilize it. For myself, this required me to learn just enough to get the framework to do what I wanted, and sometimes I never would have a full understanding of what I was doing and (most likely) wrote code contrary to framework’s opinion, breaking it to bend to my will. For Javascript in particular, it was nice to have experience across many different frameworks and learn what I liked and didn’t like, but I never really mastered any of them or had the chance to do so, because I was always on to the next one.
Working at BuzzFeed, I’ve got one JS framework I need to learn (it was also surprisingly one I haven’t tried until now, so refreshing!). This is not to say my knowledge of all the other frameworks and aspects of web development have been thrown out the window; contrarily, I use that knowledge for context when writing code here or discussing methodologies in how we’re building products here at BuzzFeed. By honing in on one set of opinions and conventions, I can focus on shipping good code with sound logic. Essentially, I have more brain space and time to working on all previous list items: doing it right and good collaboration among other engineers.
5. I’m Not An Imposter
I’m about to bring it down and get a bit introspective.
I believed for a time while looking for a new job and applying to other companies that I was not a good enough web developer because I wasn’t singularly proficient at a small smattering of technologies. I’ve met a few other agency web developers and freelancers that feel similarly. This feeling was more exaggerated for myself because the agency gig was my first job out of college, and I was in the agency world for five years (which according to some of my colleagues is a long time). Was I too closed up in this agency-dev bubble? Did I learn enough? Was what I was doing relevant to current web landscape? Am I doing enough side projects to learn new web tech? Am I good enough?
I had based this bar of being “good enough” on my first interview during my college search was for A Big Tech Company, and I did not make it past the first code interview. It was reiterated to me many times by my friends and colleagues that the interview was five years ago: I must’ve learned something doing all the work I did at the agency, right?
I absolutely did! I learned a lot of things in terms of soft and hard skills. I gained wide breadth of technical knowledge. No depth isn’t necessarily a bad thing, and the wide breadth allowed me to figure out what I actually like and am passionate about in web development and software engineering. I apply a lot of what I learned over time at the agency to what I’m doing now, and I realize I have a good perspective working on the Ads Experience team here at BuzzFeed (going from the side of wanting to put ads on All The Things to making the ads native and subtle). Also, you can learn all of the Javascript frameworks you want, but as long as you’re coding, you’re getting better at coding.
I’m still relatively new at BuzzFeed, and I’m still constantly learning! It’s a refreshing change, and I’m very excited for all of the projects and products Tech is going to be rolling out!
To keep in touch with us here and find out what’s going on at BuzzFeed Tech, be sure to follow us on Twitter @BuzzFeedExp where a member of our Tech team takes over the handle for a week!
