A Day in the Life of Narrative Dev

You sit down, you pour your coffee… Now what?

This doc goes into what can be expected from a day in the life of a software developer at Narrative. Any given day might not run the entire gamut of the everything below, but it should give some idea of what to expect.

Code

Feature Implementation

The first and most obvious category of work is implementation and coding. This covers everything from improving an existing feature to setting up an entirely new service to implement a new feature. Some examples of project work:

  • Improving an existing spark report by reducing the amount of shuffling it has to do.
  • Writing a new spark report to generate analytics on data that we have ingested.
  • Creating a frontend component using d3.js to display the aforementioned analytics.
  • Setting up a stream processor to ingest data that a new partner is sending to us.

Deployment and Ops

Deployment and ops is very much a part of regular life. Although there are safeguards to prevent accidental deletion of production resources, there are no prod-environment gatekeepers per se. At the end of the day, developers are trusted to provision resources and deploy systems as needed. In exchange for this trust, there is an expectation of ownership and responsibility – developers should be conscientious about their resource usage, and “if you break it, you fix it.”

Not Code

Code reviews

Code reviews are a keystone habit for a quality-driven dev culture, and everyone is expected to both review code and have their code reviewed. They are great because:

  • Having multiple sets of eyes on a piece of code is an easy way to evaluate its readability and clarity. It also lowers the bus factor by distributing knowledge of what code lives where and why.
  • The author of the code gets the benefit of different perspectives on code structure and style, as well as having any unexpected bugs / edge cases pointed out.
  • The reviewer gets to learn how other developers are writing code and if there are any useful libraries and techniques that they can adapt for themselves.
  • Last but not least, knowing that others will be looking at the code naturally encourages more effort in keeping quality high.

At Narrative, code reviews happen as a part of the regular development process, i.e. we review all code as it is pushed and there is no specified “weekly code review” meeting where everyone brings snippets for review.

Design reviews

Design reviews are basically code reviews at a higher level. New projects and large features usually start with a design doc and review. Design docs are a great tool for gathering early feedback and encouraging discussion between developers and business stakeholders before anything gets set in stone. A doc is a lot easier to change than code, and code is easier to change than a running system. Conveniently, it also serves as great documentation for new hires or anyone else wondering “why was X done this way?” A typical doc will answer questions like:

  • Why are we building this? How does it benefit the business / team? Are we making any assumptions about our customers and future product direction?
  • Is there any existing work we are taking advantage of? Why or why not?
  • What are the tradeoffs we are making? e.g., do we care more about space consumption or speed? Does this feature need a new RDS instance, or will a tiny DynamoDB table work just as well?
  • What is the requirement for uptime? How can we tell if something is wrong? How screwed are we if S3 goes down, and are we OK with that?

The design doc is written by whoever owns the feature in question. Typically, initial review happens via comment threads in Google Docs, and is followed by a quick Hangouts session to make sure all outstanding issues are resolved before proceeding.