Workflows Code Diary Entries

This is part of the Semicolon&Sons Code Diary - consisting of lessons learned on the job.

• Always check if an alias is taken before defining it
• Be wary of hard coding array positions
• Before researching a feature carefully inspect if already there
• Build seeders out of factories instead of maintaining independent logic
• Calling a library function incorrectly means your stacktrace may not mention your code yet still be useful
• Check version number constraints before writing code
• Check version number of docs and tutorials always
• Checklist for faster more accurate programming
• Configure readline to paste multiline code properly
• Consider variable naming strategy upfront
• Create objects with nested brackets on new lines
• Data wrangling should be end to end ipempotent
• Default form values make manual testing easier
• Do not assume log output of a certain tint is irrelevant
• Do not repeat documentation for API endpoints
• Don't use higher level provisioning and config tools until you know the basics
• Download libraries to your project folder
• How to get up to speed on a legacy codebase
• How to make REPLs without reload reloadable using SIGINT
• How to query locally generated docs
• How to sanity check object data
• If it mysteriously freezes look for loop
• In forums the best data is probably last
• Inspect xml or html special char production on command line
• It is simpler to avoid capitalizing acroynms
• Keep your code in one language as a naming convention
• Know when to solve a problem with a descriptive vs imperative approach
• Logs give false security when the underlying data has not been verified
• Look at end of life when choosing versions
• Never lint a codebase while other people are committing to it
• Pay attention to the log level
• Pay attention to types when debugging
• Prefer git reset to undoing for removing false starts
• Principle of minimal invasion in codebases you do not know
• Professional expectations
• Proof read comments with spell check on
• Proof read generated code immediately for pluralization and type errors
• Put things in consistent tabs
• Read the console output of object properties when debugging
• Read whole readme in outline before jumping in and following steps
• Reference existing names instead of guessing
• Remove comments when pasting then modifying code
• Resist urge to refactor until you have verified the problem actually exists
• Sanity check data exports before handing off
• Set editor config before touching legacy code
• Spot config related errors
• Step 1 with building API check if available in region
• Strategies for dealing with naming convention differences across language boundaries
• Test as far as you can even if you are limited
• The first step is always to get the code running locally
• The process of randomly try things till it works sucks
• Think if going to subtools would help
• Use a script for deploying or staging
• Use end to end tests to understand new codebases
• Use githooks and NOCOMMIT comments to prevent dangerous commits
• Use standarized naming conventions for your personal projects
• Watch out for linters introducing errors
• When a bug is encountered check for parallels elsewhere
• When copying code take no more than absolutely necessary
• When copying code to another codebase scan for constants
• When doing one last thing check deliverable works in full
• When generating code in another language it is easier to debug if you save it to its own file
• When removing code grep project wide
• When something does not work on a colleague's machine suspect gitignored content
• When using new syntax switch whole project at once
• When working on multi platform code switch platform daily to eat own dogfood
• When you have a bug look up every function you do not understand
• Wrap the magic numbers of external entities
• Write migrations with foreign key dependencies first
• You need to recreate production ENV locally to reproduce bugs