Because the best marketers deserve great content.
Our engineering culture
On Friday I was talking to Kevin, another member of the team here, about our ongoing search for a VP of engineering. At some point in the discussion, he challenged me to actually write out what I appreciate about being a programmer at Percolate.
I’m convinced that culture is pretty vital in any engineering effort, so it sounded like an interesting challenge. There are a few basic aspects of Percolate’s coding culture that I think are particularly unique and enjoyable, so I’d like to talk about those in no specific order.
Choosing the right tool for the job
One of the things that I value most about the writing software at Percolate is that preference is always given to the right tool for the job, even if the right tool is outside of our familiarity.
This results in a rich ecosystem of Python libraries: our core app runs in Django, but for smaller services we use Flask, and for nascent hacks we use Google’s App Engine. For most modeling we use relational databases, but for more exotic kinds of data we turn to alternate storage technologies like MongoDB or Amazon’s DynamoDB (depending on structure and access patterns). Sometimes we distribute work with a message queue, sometimes with a Redis set: It all depends on which technique will best solve the problem at hand.
The autonomy to solve a problem with the best technology available is a luxury for programmers. Most organizations I’ve been exposed to are encumbered, in varying degrees, by institutional favorites or “safe” bets without regard for the problem to be solved. Engineering at Percolate has so far been free of that trap, which results in a constantly engaging, productive mode of work.
I also appreciate that our culture recognizes another implication of the “right tool for the job” principle: We’re wary of the use of a tool just for novelty’s sake. We recognize that there are right and wrong tools within the context of a particular problem, even if in degrees. Tools bolstered mostly by hype are commonly regarded with caution around the office.
A culture of automation
On your first day as an engineer at Percolate, ten minutes after cloning our development repo (colloquially called Devolate), you have a full, usable Percolate instance with the latest production code. Everything from the message queue to the Nginx process is configured and running on your virtual environment, thanks to CFEngine (which also manages our production servers).
After you create your first branch and make a code change, you open a pull request on Github. A Jenkins build is automatically initiated for your branch and test results are reported back to your pull request without you doing anything.
One of our internal tools notices that a human reviewer left a comment OK’ing the PR; it also notices that the tests have passed, so it automatically transitions the task for your branch to QA. Our QA engineer, Mahima, stages your branch with the assistance of a Hubot instance that manages our distributed stage.
Your branch passes QA and is merged to master. API documentation is then generated and pushed live, drawing from automated test results and controller code to provide usage examples. Your code is then deployed to our production servers with one command. Graphite monitors visualize how the system responds to your change on two big flatscreens.
Automation is a priority here; it’s really the core of our development methodology. There is a strong consensus on the team that removing any and all boilerplate in the development cycle makes writing code not only more enjoyable, but it allows us to ship frequently and safely.
Excellent coffee-making equipment
Appreciation of the Unix philosophy
Not all of our engineers are die-hard, crusty Unix aficionados (though one maintains a pretty heavy-duty commandline tool written in, of course, C), but most everyone on the team seems to have an appreciation for old-school Unix philosophy.
- Less is more: We don’t build cache layers until we’ve proven we need them.
- Simpler is better: Do the silly O(n^2) loop if it’s more readable, then refactor it when (if!) it becomes a problem.
- Be clear: Our style-guide encourages use of the grep test.
- Clean boundaries: Our frontend is powered off our own REST API; decomposing the system into services is a priority.
Rapid prototyping, a classic Unix technique, is a big part of our philosophy. We’ve found that releasing features in small, steady increments (usually starting with the very backend) is key in building features that are seamlessly deployed, timely, and well thought out.
Strong personal responsibility
No matter how junior you are, designs are never handed down wholesale. Each engineer is responsible for designing, proposing, and tailoring an architecture for the problem at hand (of course, there’re always other smart folks around to informally gut-check ideas, which happens often). Consequently, each engineer takes responsibility for the feature and any subsequent bugs that arise.
This is far from a unilateral process though; integration and negotiation with other teams are constants. A backend engineer might have to come to agreement with the data and frontend teams, which are a great opportunity for sanity checks. But a strong sense of agency is an important part of how engineering works at Percolate.
This provides an excitement and autonomy that are important in any creative process.
Being involved with communities is an integral part of being an effective engineer. It’s an easy way to learn, stay current, and drink too much.
Open source tools have allowed us to build Percolate, and we’re committed to the idea that opensourcing is the fastest way to quality. We’ve patched open source projects (backbone.js, ddbmock, fake_dynamo, RestKit). We’ve also opensourced some of our own (jennifer, jsonmatch) with more to come.
Culture stems from people. Good people are a prerequisite for good culture, and there is no substitute for being surrounded by those who are dedicated to perfecting their craftsmanship, writing beautiful code, and creating exciting product. My co-workers are, by far, the aspect of our engineering culture that I enjoy most.
Help build our culture
If these values and ideas sound appealing, you should get in touch.