EngineeringWiki
  • Introduction
  • Top level Overview of the application
  • FAQs
  • Back End
    • Agent Pipeline
    • Mention Pipeline
    • Profile Pipeline
    • Errors
    • Overview of the Mention/Profile/Cluster Process
    • Adding a New Service
    • Activity and Status Tracking
  • Setup
    • Overview
    • How to Setup Your Local Machine
    • Setup - Cloud Machine
    • Infrastructure
    • Docker
    • Bash Commands
    • Setting up front end in Ubuntu 16.04 desktop
  • Gems/Libraries
    • Bax
    • Creating fixtures for Unit Tests
    • Audienti-Retriever
    • Scour
    • Haystack
    • Audienti-Indexer
    • Audienti-Api
    • Handler
    • Blackbook
    • Allusion
  • Code
    • Multi-step Modal Wizard
    • Structure
    • Audienti DataTables
    • Javascript
      • Passing Props From Root
      • Looping in JS
      • Binding Actions to App
      • CSSTransitionGroup
      • Code Best Practices
      • Reducer Updating an Array with Item in Middle
      • Organizing Javascript
      • Filter Array by Id
    • Design Language
  • Working
    • PostgresSQL
    • S3
    • Terminology
    • Interview Tests
    • Application Descriptions
    • Best Practices
      • Code Organization
      • Code Documentation (using Yard)
      • Git Workflow
      • Tasks and Queues
      • Working in Backend
    • Profiles & Enrichment
      • Profile ID Rules
  • Management
    • API Management
    • Bastion
    • Splash Proxy
    • Rancher
      • OpenVPN Server
      • Traefik Reverse Proxy
  • Teams & Interviews
    • Interview Questions
  • Culture
    • What Makes a World Class Engineer
  • Situational Statuses
    • 2017-11-03
    • 2018-01-09
  • Operations
Powered by GitBook
On this page
  • What makes a world class engineer?
  • Our Principals
  1. Culture

What Makes a World Class Engineer

What makes a world class engineer?

  • Analytical problem solving with code

  • Technical communication--I can implement your approach just from your description.

  • Engineering best practices and approach--debugging, code structure, referring to documentation, patience, making code that others can "pick up", DRY code, Small Code, Single Responsibility Principal

  • Non-technical communication (empathetic and thoughtful communication)

  • Language and computer science experience

Our Principals

  • DRY (don't repeat yourself) - Every piece of knowledge must have a single, unambiguous, authoritative representation within the system. Practically speaking, if something does something, there should only be 1 place we're doing it.

  • KISS (Keep it Simple Stupid) & YAGNI (You aren't going to need it) - Don't overengineer components. What's the smallest, simplest version of this that we can write? The easiest code to maintain is the code we don't write. 80% of the time is invested in 20% of the functionality. Opt for removal and simplicity over complexity and clever.

  • Once and Only Once - You should only declare a behavior one time. There should be a single version of truth. When you have multiple versions of code, there often becomes subtle differences in code that causes things to behave unexpectedly (buggy). A Single Point of Truth keeps this from happening. Practically, opt for factories in your code.

  • Open-Closed Principal & Dependency Inversion - Your code should be open to extension, but closed to modification. If someone wants to extend your code, they should be able to do it easily. They should have a minimal interface, and no undeclared requirements.

  • Do One Thing & Separation of Concerns - Each class or module should only do 1 thing. Single Responsibility Principal. If things are mixed together, then they should be broken down into smaller items. If your class is greater than 100 lines, think about if it's breaking this rule. If a method or function is longer than 10 lines, is it doing too much?

PreviousCultureNextSituational Statuses

Last updated 7 years ago