Welcome! You're now a software developer.

I originally wrote this as a part of our new analyst onboarding program back in June of 2017, shared with new analysts on their first day. It's as true today as it was the day I wrote it, so I wanted to publish it more broadly. Maybe you'll find it useful!

You are a developer

Let's get one thing straight: writing analytic code is writing code. While the purpose of analytic code is very specific (supporting insight generation from data), that doesn't make the code produced in this effort any less "code" than the code behind a mobile app, cloud software platform or operating system. In each case, the code has inputs and outputs and processes data.

While you may or may not think of yourself this way, the minute you start writing analytic code, you are a developer. This may be the first time that you've held a job where your primary job was to develop software, and that's ok! You've probably written plenty of code before, but you may not have been as focused on writing good code. Your code was likely written to solve a very localized problem, wasn't checked into source control, didn't go through code reviews, and wasn't relied upon by a large number of people for a long period of time. This describes most analytical code ever written, and conditions like this encourage analysts not to think very much about code quality.

At Fishtown Analytics, code quality matters. The code we write forms the foundation for the analytics at well-funded, high-growth businesses. Code that you personally write will end up powering the analytics at companies that grow to be worth billions of dollars. It will be in production usage for years after you're no longer working with them. Dozens of analysts will read, enhance, and fix bugs in it.

The fact that your code is so mission-critical forces you to focus on producing code using a different mental model and a different set of processes. Rather than saying "How can I get this done?" you'll start asking "How will this break?" You'll start finding commonalities between analytic questions and you'll learn how to write code that solves the generic, not just the local, case. You'll run into performance problems and learn how to write code that runs fast. You'll spend more and more time writing tests and documentation that will help your code continue to work well far into the future. This is the way good software developers think.

On a very practical level, writing good code simply produces better outcomes:

• Writing good code will produce better outcomes for our clients. The analytics we build for them will be more performant, reliable, and maintainable if we take care to build them well.
• Writing good code will produce better outcomes for us. Not only will it cause our clients to be happier and therefore renew their contracts and refer us business, but writing good code actually allows us to do our work in far less time, and thus be much more profitable and work fewer hours.

There will be growing pains as you learn to think more and more like a software developer. Your first six months in this workflow will require you to learn new things on an almost constant basis. As you gain experience, you'll be shocked at how thinking in this way becomes second nature and at how you magically seem to be able to do more, and better, work in far less time and with less stress.

How software developers think and work

Software developers work differently than most professionals, and this difference stems from two facts. First, developers' work scales: thirteen software engineers built Whatsapp, used by a billion users before it was acquired. Every line of code in that codebase was worth thousands of dollars. Second, developers create leverage: they are constantly involved in the process of making their own work, and that of their peers, more efficient. A single highly skilled software developer today can accomplish tasks that her peers even ten years ago could not have dreamt of.

Scale and leverage lead software developers to different ways of working. We want you to adopt these ways of working, too, but we know that these simple axioms will take a long time to sink in.

1. Code defensively. Software developers have scars. Poorly written code can ruin weekends, or years, or very large companies. Every software developer knows from personal experience how poor decisions have a way of metastasizing. This makes software developers cautious: they're always thinking about the ways in which their code can break. Learn to test for common errors. Go through mental checklists. Listen to your gut. Spend the time to do things the right way.
2. Write reusable code. It is very common to copy and paste when doing analytical work; every Excel sheet is contains rows of copied cells and most SQL starts with a copy/paste from an existing statement. Software developers don't copy and paste code, they write reusable functions and classes. If you find yourself wanting to copy and paste, it's probably a good opportunity to think about modularity.
3. Write readable code. Software is a collaborative process. While most projects start small, it is the nature of successful projects to grow in both importance and team size. While a project may seem like a toy at first, that toy may turn into Twitter, and onboarding new software developers to a poorly written codebase always has bad outcomes. Spend real time writing, then revising your code. Ask others how they would solve a problem when you don't feel like your solution is as good as you want. Be concise, but not at the expense of clarity.
4. Nothing is magic / you can learn anything. Software developers have this attitude that nothing is magic. While normal humans think about things like blockchain consensus protocols and deep learning as almost magical, software developers recognize that understanding complicated things is just a matter of time and energy (and lots of reading!). You're frequently going to touch powerful technology, and the more you understand how these technologies work, the more effective you'll be. You're surrounded by incredibly smart and knowledgable people: start by asking questions.
5. Sharpen your tools. Software developers build their own tools, and they spend real time during their workdays doing this. Good tools multiply the effectiveness of everything you do. dbt gives you the ability to sharpen your tools as well: by investing time writing macros, tests, and common packages, you invest time up front to make yourself more effective in the future. And because dbt is a part of a rich ecosystem of tools like git, bash, vim, and emacs, there are endless ways for you to make yourself more effective. If you realize you work the same way today that you did a month ago, that's a good time to pause and do some tool sharpening.