Skip to content

Latest commit

 

History

History
162 lines (145 loc) · 9.51 KB

README.md

File metadata and controls

162 lines (145 loc) · 9.51 KB
Raw

The Creed of Software Engineering

by: Daft Labs

in no particular order:

  • focus

  • ideal stack

  • configurations

  • learning? [great advice] (https://np.reddit.com/r/learnprogramming/comments/2qznse/i_need_serious_help_learn_to_program_was_my_new/cnb1luk)

  • math not feelings

  • names matter

    • branding
      • brand names and domain names should match
      • names should:
        • be easy to pronounce
        • be real words
        • contain as few syllables as possible
        • have no missing or replaced letters
        • not sound like other words (ex: daft gets confused with deft regularly)
        • the goal is to not have to explain or spell the name every time you tell it to someone.
        • names aren't as important as the brands you build them to be.
        • generators
    • programming
      • don't abbreviate
      • when the meaning of an element (variable/method/class) changes, change the name (but srsly, put serious thought into the names)
      • Be consistent.

  • less cogs in the machine with the same level of functionality should be the goal

  • programming

    • http://en.wikipedia.org/wiki/Rubber_duck_debugging
    • languages can be messy. you can do a lot of things a lot of different ways. have a convention
      • php: http://pear.php.net/manual/en/standards.php
      • Be consistent.
      • line length should be less than 100 characters (github's panel width)
      • clarity of code and readability are more imprtant than basically everything else
      • frameworks have conventions
        • don't roll your own
      • don't comment out code. this is why we have version control.
      • your code should be clean enough to read without comments.
        • comments are okay in rare occasions like heavy math, but ultimately are out of date as soon as you write them.
      • if you're unsure about syntax, test it! Use a REPL
    • don't get defensive when talking about the product. (ex: don't shy away from things you know are hard)
    • have tests
    • all code should be pull requested, all members of the team should read pull requests and give some quorum of 🍰 or 👸
      • tests should be run against every pull request automatically
      • blockers should be explicitly stated
    • markup and css belong in templates, not controllers or models
      • there are these things called templating languages, use one
    • don't have credentials under version control
    • don't commit dependency code (i.e. jquery, bootstrap)
      • use composer or npm or gems or submodules or anything
    • don't commit "built" files like compiled sass, etc.
    • don't roll your own framework
      • bootstrap for markup and chrome
      • jquery for javascript dom management
      • lodash for more javascript helpers (this has some overlap with jquery, use jquery for dealing with jquery objects and lodash for everything else)
      • angular for javascript interactions (lets you build most of your ui javascript interactions directly into the markup instead of having one off scripts for stupid things. beware of large data sets)
      • laravel for php
      • express for nodejs
      • rails for ruby
      • django for python
    • evaluate performance when it becomes a business problem
      • seriously, don't prematurely optimize
        • no really, you aren't going to have a million users day one of launch. if you do, good for you. deal with it then.
    • globals are bad. mmmm'kay?
    • form posts ALWAYS redirect. dont just process the post and render something on the same request
    • know a little bit about security
    • keep your bedroom clean
      • commit (pun intended) a meaningful amount of time to optimizing and cleaning your code.
      • pay technical debt as soon as possible.
      • some times it's just too messy. the sign of a great leader is someone that is willing to throw away all of their code.

  • two people working on a project, especially on the tech side, are infinitely better than one (http://feedfront.com/archives/article006974)

  • ideas are worth almost nothing; execution is worth everything (http://www.shoemoney.com/2014/05/05/find-technical-co-founder)

  • ops

  • don't hire anyone that can't use git from the command line or isn't willing to learn (http://nfarina.com/post/9868516270/git-is-simpler)

  • project management and communication are very important

    • programmers define difficulty
    • business defines goals
    • product defines priority
    • nobody bitches. we're a team.
    • time doesn't matter. results matter
      • the number of hours worked is not a representation of productivity
    • sleep is important (majestic if you will)
    • invest in tools that save time

  • Basically anything here: http://pivotallabs.com/category/tech-talks

  • all programming languages are broken. watman

  • programming sucks

  • use the right tool for the job. don't try to fit a square peg in a round hole. (ex: don't do caching in mysql. this is why we have memcached).

  • don't use caching until absolutely necessary. it's for scale, not a bandaid for terribly optimized apps.

  • use math, not feelings. that doesn't mean you can't use feelings sometimes, but you have to admit it.

    • Be consistent.

  • know the value of your resources

    • sometimes it's cheaper to have a human do the job instead of writing a program (ex: modify these 10 records)
    • if a server is messed up, and it's not a recurring problem, since you use chef, you can just nuke it and make a new one. don't try to fix the problem.
    • http://en.wikipedia.org/wiki/Peter_Principle - promoting from within isn't always a good idea
    • work on high value, low cost features first.

  • product

    • UX Checklist
    • functionality is more important than design. build out your features before adding chrome. UX people first, programmers second, designers third.
    • know where you're going, but build your MVP first. (don't build an oil tanker when you need a tugboat)
    • MVP should be the smallest possible (not completely useless) piece of the great whole
      • build for what you need now, not what you expect you might need in the future
    • pages should have only one call to action
    • be vocal about things you think are broken or inefficient
    • Be consistent.

  • team dynamic is important. bolster the 'family' feeling by doing unstructured extra-curricular activities

  • http://highscalability.com/

  • https://www.destroyallsoftware.com/talks

  • invest in equipment that increases efficiency, but don't invest in things that satisfy your ego.

  • pivotal and git integration

  • you can't make everyone happy

  • and most importantly