Developers Reference

• Coding Standards and Style
  • Principles
  • Literature
  • Names
  • Files
  • Locality
  • Error Handling
  • Comments
  • Minimize Code
  • No tabs
  • Code Quality
  • Coding Standards for Specific Languages
• Project Structure and Ops
  • Project Requirements
  • Automation
  • Project Structure
  • Front End Development
• Architecture
  • Getting Started
  • Components
  • Architecture Models
  • Implementation Level Stuff
• Dependency Strategy
  • How to Pick Dependencies
  • Javascript Frameworks
• How Countable Uses GIT
  • Git Branches
  • Contributing To A Project
  • Hotfix
  • General GIT Guidelines
  • Tips for Creating A Pull Request
  • Tips for Code Reviews
• Python
  • Python Code Standards
  • Names
  • Common Gotchas
  • Debugging Python
• Django Standards
  • Client Cache Management
  • Use LTS Django
  • Read 2 Scoops of Django
  • Patterns
• HTML and CSS Standards at Countable
  • HTML Coding Standards
  • CSS Coding Standards
  • SCSS
  • Javascript, HTML and CSS Formatting
• Javascript Best Practices
  • General Javascript Standards
• jQuery
  • You can do PubSub with jQuery
  • Prefer Event Delegation in jQuery
• Vue and React
  • References
• Prototyping
  • Prototyping Basics
  • Get A Prototype in Front of Real Users ASAP
• Testing and Bug Reporting
  • Testing Principles
  • Bug Reporting Checklist
• Training
  • How To Learn
  • Core Training
  • Further Training
  • References

Purpose

The purpose of this section is to standardize key (not all) engineering processes in order to improve the team’s performance, and take advantage of an experience curve by eliminating arbitrary process differences.

Scope

This folder is for topics related to programming and technical architecture.

Principles

This is how we build things.

• Build a prototype first to validate everything (market, feasibility, usefulness). It’s encouraged to take shortcuts as long as your project is just a prototype and not used in production.
• Get feedback on your work by shipping it to real users at least once a week, ideally every day. If you can’t ship to real users, ship as much as you can to internal stakeholders.
• When a prototype is validated, it transitions to a product and must be made maintainable. This means changing emphasis from testing the user experience as early as possible, to reducing technical debt for the long term.
• When working on existing projects (products), always leave things in a little better state than you found it.
• Take special care with error condition handling, as this a key to stability in the long run. For every error case, is it something we need to know about? If so, log it to Sentry. If the application is in an invalid state it’s better to crash and restart as early as possible (return 500 HTTP code). For validation problems (user error), return a 400 http code and refuse the operation. We don’t generally need to tell the team when this happens.
• We have Coding Standards based on auto-formatters where possible, which include standards for structuring projects which are based upon what we’ve learned.
• We operate based on principles in 12factor.net, see implementation here
• We are intentional about what dependencies we include in our stack

Developer’s Guild Meetings

The developer’s guild exists to:

• Develop lightweight standards, style and conventions that reduce or avoid technical debt and continuously improve code quality across all projects
• Make it easier for Countable developers to switch projects, knowing what conventions should be used globally.
• Create a great learning environment where we can all help each other improve as devs.
• Help Countable deploy better quality work in front of real users more quickly.

We accomplish this via:

• Monthly meetings with workshops and presentations.
• Mob / pair coding sessions.
• Code reviews.