I was aksed if I’d share my required reading list for new developers at PivotCX. It’s pretty short, and the goal is:

  • Have common language to describe problems and solutions.
  • Understand common patterns in development to avoid re-inventing the wheel.
  • Have a shared, common understanding of the tools we use to build software.
  • Establish a culture of learning where we put problems on trial instead of people.

None of these documents are dogma, and should be approached as guidelines, not as hard-fast rules. We’re wise to remember Ralph Waldo Emerson’s warning:

“A foolish consistency is the hobgoblin of little minds”

So without further ado, here’s the list:

Being Part of the Team

Need, Approach, Benefits, Competitors (NABC Model)

A very helpful way to frame up conversations that lead to actionable outcomes.

The Kanban Guide

We use Kanban to manage production. This is a short and to the point primer.

Agile Manifesto

We’re an agile shop. This is what agile really is all about.

Why Perfect is the Enemy of Done

You’ll hear this saying a lot. It does not mean a shoddy product that works is done. Here’s the thinking behind the saying.

How to Create a Culture of Learning

Here’s what the whole “culture of learning” thing is all about.

On Building Software

The rest of the list is really about building software and the tools we use to do so.

Git – The Simple Guide

Some tools are just as important as your editor and favorite computer language. So it is with source control. We use git for source control. Here’s what you really need to know to use it.

The Big Little Guide to Message Queues

We make chat and communication software, so understanding message queues helps a lot.

ETL and ELT Explained

Loading data is something we do a lot. Understanding the two common patterns for doing so can save you a lot of time and approach it consistently, and confidently.

SQL Tutorial

If you haven’t spent a lot of time with SQL, you are doomed to reinvent the database badly. You don’t have to be a DB admin, but being comfortable at an SQL prompt will help you build better software. While we do use No-SQL in some of our products, most of the time the right answer is SQLite or Postgres depending on the application.