I was aksed if I’d share my required reading list for new developers at PivotCX. It’s pretty short.
The goal is simple:
- Have common language to describe problems and solutions.
- Understand common patterns in development
- Avoid re-inventing the wheel.
- 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”
— Ralph Waldo Emerson (and PEP8)
So without further ado, here’s the list:
Being Part of the Team
Need, Approach, Benefits, Competitors (NABC Model)
NABC is a model that helps us pick the right features and right product to make our customers happy and beat the competition.
The Kanban Guide
We use Kanban to manage production. Kanban is a system that helps ensure everyone on the team is productive, and ensures work gets done in the right order. This is a short and to the point primer.
Why Perfect is the Enemy of Done
You’ll hear this saying a lot. It does not mean a shoddy product that works is ok.
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
Building software is a team sport.
Agile has changed how software is built. The Manifesto is really helpful This is what agile really is all about.
Git – The Simple Guide
Some tools are just as important as your editor and favorite computer language. So it is with source control. Here’s what you really need to know to be effective with git.
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 help you approach data consistently, and confidently.
If you haven’t spent a lot of time with SQL, you are doomed to reinvent the database poorly. 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.