clypd’s workflow involves offline processing of files from our clients and partners. They drop compressed ZIP files to our SFTP servers which are then picked and processed by our workers. The processed data is crucial in powering clypd’s advanced audience targeting platform. Because these files are critical to our business, we have monitors that ensure correct parsing and transformation of the files.
What do you do when your parents pull you out of school to go to Disney World but you have a project due the next day?
However, there were a few issues:
In this blog series, we interview a member of the clypd team every month. Find out what drives us, what makes us tick, and what we do outside of the clypd office. In this month’s clypd Profile, we talk to James Garfield, Principal Software Engineer.
Can you describe your job and an average day working at clypd?
I like to get in about an hour before our stand-up meeting to have time to make myself an Aeropress coffee, read my email, and catch up with engineers on other teams. I’m lucky enough to get to work on projects all over our tech stack, from standing up new platform APIs, integrating with data-science, and helping our UI team use state of the art technology. I try and fit all my meetings to synchronize on my projects in the mornings, so that I can concentrate on writing code in the afternoon. I also like to round out the day with a rousing game of foosball.
I work on the UI team, which means that I get to help develop our user-facing features. Day-to-day what I could be working on anything, from UX brainstorming to re-organizing our database to coding up pretty and interactive charts!
I like to arrive a half hour before stand-up at 9:30 so I have a bit of quiet time in the morning to eat a pastry and drink coffee while I read my email. After our stand-up, I alternate between working on my own projects, helping out teammates, and going to meetings.
At clypd, almost every feature we build is data-driven. It is therefore important for the data access layer of our Go platform to be powerful, yet easy to build upon, maintain, and debug. Today we dive into the design of the clypd data access layer, the frameworks we chose, and how we augmented them.
A huge benefit provided by Go is simplicity throughout the clypd stack. Dependencies, particularly third-party libraries, are often opaque in other programming languages due to varying code style, source code that is difficult to find, or abstraction layers that are challenging to see through. The source code for any library is just a click away in Go. Design idioms found in dependency libraries are usually similar to the ones we use, which ensures that the entire system is easy for our team to comprehend.
At the beginning of 2014, I was thinking about how we might create a meaningful review process. I am not a big fan of only yearly reviews. I don’t know about you, but I have no idea what I was doing a year ago and often, what was important at this time last year is not relevant now. So, how do we make a better process that helps drive career growth?
I already had a one-on-one process established where we have the “how’s it going?” discussion. I always start the conversation with “Are you having fun? Are you learning stuff? Are you building awesomeness?” The response I always get is “yes, yes, yes." Then I ask, “What did you learn? What part was fun and what was not? What kept you from building awesomeness?” And that’s where the interesting conversations start. For me, learning, fun and building are intertwined.
Almost a year ago, we blogged about our reasoning and methodology for choosing Go as our next generation platform here at clypd. A year is a long time, both in software technology and in the lifetime of a startup. Since paper is the traditional gift for a one year anniversary, it seems appropriate to write down our learnings so far.
When we posted “Getting to Go,” we included a list of the selection factors we used to evaluate potential platforms. The list includes
Thorough testing continues to be a key tenet of software development at clypd. Quality is paramount, but shipping code quickly requires us to be efficient in how we search for bugs. We’ve found innovative ways to unit test individual Go packages of our programmatic television ad platform as it has grown in its capabilities. The construction of a similarly efficient mechanism to test large portions of the whole system has taken our test automation to the next level.
At clypd, we place a lot of value on testing as a mechanism for ensuring code correctness and our approach to testing constantly evolves. We’ve spent the past few months learning and creating a new approach to mocking and testing functions that need to access data, whether from a database, a file, or over the network.