97 Things Every Programmer Should Know

Posted in Coding
  1. Act with Prudence
    • take extra care to avoid tech debt
    • if you must accrue it, track cost appropriately
  2. Apply Functional Programming Principles
    • learn to apply functional principles to make your code simpler and easier to debug
  3. Ask, “What Would the User Do?” (You Are Not the User)
    • the user may not think like you
    • best way to understand them is to watch them
  4. Automate Your Coding Standard
    • automate checking of standards and incorporate into build process
  5. Beauty is in Simplicity
    • strive for readability, maintainability, speed of development and beauty
    • enabled by simplicity
  6. Before You Refactor
    • assess current code base, refactor incrementally, ensure test coverage for changes
    • make sure refactor for valid reasons
    • refactors can fail, assess risk
  7. Beware the Share
    • shared code increases dependency
    • similarities may be accidental
    • check your context first
  8. The Boy Scout Rule
    • leave campground cleaner than you found it
    • systems would gradually improve
  9. Check Your Code First Before Looking to Blame Others
    • more likely issues are due to your code than underlying technologies if mature
  10. Choose Your Tools with Care
    • tools have different assumptions, lifecycles and maintenance costs
    • start small and can try to isolate to avoid lock-in
  11. Code in the Language of the Domain
    • code in the domain not algorithms
    • make domain concepts explicit
  12. Code is Design
    • in construction, reduced build cost would reduce design quality
    • speed becomes central push, pressure to use incomplete design
    • tests are simulations and design not complete until validated
    • need to dedicate yourself to mastering design craft
  13. Code Layout Matters
    • read code more
    • easy to scan with standardized patterns
    • compact, fit less state in head
  14. Code Reviews
    • make reviews about not only fixing mistake but also share knowledge and establish common guidelines
    • share burden with roles and involve other people
  15. Coding with Reason
    • divide sections and argue correctness with peer
    • avoid goto, global vars
    • use small scope, immutable objects, descriptive names, few params, narrow interface, avoid setters
  16. A Comment on Comments
    • use comments they are not evil
    • header comments for providing info on how to use
    • inline comments for someone trying to edit/fix
  17. Comment Only What the Code Cannot Say
    • comments should be treated as code
  18. Continuous Learning
    • responsible for your own education
    • books, hand-on, mentor, study framework/libraries, teach, conferences, podcasts, learn domain
    • when fixing bug, try to really understand what happened
  19. Convenient Is Not an -ility
    • good API’s follow consistency and forms vocabulary for an expressive language
    • convenience of caller
    • easy to use
  20. Deploy Early and Often
    • make sure assumptions made in development environment hold
    • refactor deployment process as you go
  21. Distinguish Business Exceptions from Technical
    • handle business and technical exceptions separately
    • mixing can confuse the caller
  22. Do Lots of Deliberate Practice
    • getting better is about deliberate practice, not just completing the task
    • repetition and increasing mastery
    • practice something you’re not good at
  23. Domain-Specific Languages
    • take target audience into account and adapt the technical level of the language
  24. Don’t Be Afraid to Break Things
    • don’t be afraid to improve code
    • care for general health of the code
  25. Don’t Be Cute with Your Test Data
    • always consider what can happen if your work becomes public
  26. Don’t Ignore That Error!
    • always handle errors for more robust and secure code
  27. Don’t Just Learn the Language, Understand Its Culture
    • language is more than syntax, learn the patterns
    • enriches your understanding of design patterns and makes you more capable in your language
  28. Don’t Nail Your Program into the Upright Position
    • avoid complex intertwined exception handlers
    • leave useful trail
  29. Don’t Rely on “Magic Happens Here”
    • if not actively involved, the unconscious tendency is to assume they are simple
    • when magic stops, project can be in trouble
    • good to understand some and appreciate someone who does understand it
  30. Don’t Repeat Yourself
    • remove maintained code, source of future bugs and complexity
    • repeated processes that can be automated should be and standardized
    • design patterns address repetition in logic e.g. factory, strategy, also structures like db schemas
    • repetition can be necessary in order to meet performance or other requirements, but should only do when it addresses an actual problem
  31. Don’t Touch That Code!
    • local, development, staging, production
    • developers shouldn’t have access beyond development
    • QA shouldn’t touch development server
    • only release manager should have access to both
    • development should never have access to production server
    • if issues, fix and roll a patch
    • production is not the place to fix it
  32. Encapsulate Behavior, Not Just State
    • objects not just record types
    • don’t wrap all business logic in a big manager or service object
    • breaks encapsulation and methods are easily broken
  33. Floating-Point Numbers Aren’t Real
    • floating-point numbers are imprecise and can result in subtle errors
    • understand spacing
    • do not use for financial applications
    • floating intended for efficient scientific computation
  34. Fulfill Your Ambitions with Open Source
    • can work on almost any kind of project
    • need to be willing to give up free time but grow faster
    • see how someone else would implement a solution
    • real life experience in tech that interests you
    • volunteer to add documentation and tests to get started
  35. The Golden Rules of API Design
    • It’s not enough to write unit tests for an API you develop, need to write unit tests for code that uses your API
    • will learn hurdles users will have to overcome when they try to test their code independently
  36. The Guru Myth
    • people asking super general questions gurus to know the answer when they usually are better equipped to answer it
    • guru is from dedicated learning and refinement of thought process
    • not a magical barrier, but a continuum in which anyone can advance
    • gurus don’t contribute to the growth of their peers
    • need people willing to develop other experts
  37. Hard Work Does Not Pay Off
    • software development is a marathon
    • requires observation of effects and adjustments
    • need to learn more about software development in general and programming techniques
    • also requires constant learning and keeping up to date which you cannot do if always working on the project
  38. How to Use a Bug Tracker
    • good report says how to reproduce, what should happen and what did happen
    • get clarification and more context on bug
    • take time to explain why closed or changed prioritization to save justification time in future
    • make sure there is a place where everyone can find and query
  39. Improve Code by Removing It
    • remove unneeded code YAGNI
    • code should add value not amuse you
    • extra code always takes longer to write and maintain
    • do not invent extra requirements
  40. Install Me
    • if making software for others make it extremely clear what it will do and make easy to use and learn
  41. Interprocess Communication Affects Application Response Time
    • often poor response times due to IPCs looking at algorithm and DS less helpful
    • some strategies 1) optimize to fetch only what you need 2) parallel 3) cache
  42. Keep the Build Clean
    • try to have a zero-tolerance policy for compiler warnings
    • not useful if there are many / ignoring takes mental work
    • fix, suppress, or change policy to reflect what you care about
  43. Know How to Use Command-Line Tools
    • don’t only rely on IDE’s they make decisions for you
    • CLI’s help you understand what is going on under the hood
    • some tasks easier and better automated with CLI
  44. Know Well More Than Two Programming Languages
    • learn multiple languages and different paradigms: FP, OOP, procedural, logic, dataflow
    • cross-fertilization is core of expertise
    • learn idioms not just syntax
  45. Know Your IDE
    • can enforce style rules
    • many never progress beyond most basic usage
    • memorize keyboard shortcuts
  46. Know Your Limits
    • understand the capabilities of algorithms, systems, and runtime complexities
  47. Know Your Next Commit
    • understand what you’re working on and why
    • don’t go into a speculative mode without noticing
    • decompose
  48. Large, Interconnected Data Belongs to the Database
    • databases are powerful
    • used to be expensive, complex, but not now
    • handles relationships and indexing
  49. Learn Foreign Languages
    • important to not only understand machine language, but different teams/people also have their own context-specific language
  50. Learn to Estimate
    • when estimating distinguish between an estimate, target, and commitment
    • estimates should not be what is acceptable to the manager
  51. Learn to Say, “Hello, World”
    • you can try to run small snippets and experiment outside of integrated project environment
  52. Let Your Project Speak for Itself
    • give project a voice for code metrics/test coverage
    • can be done with email or instant message
    • more effective to use extreme feedback device e.g lamp
  53. The Linker is Not a Magical Program
    • learn how it works
    • concats code, connects references to symbol, and pull unresolved symbols from the library
  54. The Longevity of Interim Solutions
    • interim solutions persis because they are useful
    • easy to remain in place forever
    • motivation to rework solution will be weak
    • avoid creating the interim solution in first place
    • try to change forces that influence the decision of the project manager
  55. Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly
    • experiment with it and try to walk through common use cases
    • anticipate errors and observe how it is misused
    • modify if necessary
    • interfaces are for the convenience of users not implementers
  56. Make the Invisible More Visible
    • develop software with plenty of regularly visible evidence
    • unit tests reveal characteristics of developer quality
    • running tests reveal behavior
    • boards and cards reveal progress
  57. Message Passing Leads to Better Scalability in Parallel Systems
    • parallelism hard with shared mutable memory
    • don’t use shared mutable memory, use message passing
  58. A Message to the Future
    • think of code as a message for future maintainer
  59. Missing Opportunities for Polymorphism
    • use context, remove if/else blocks
  60. New of the Weird: Testers Are Your Friends
    • small issues in other areas may raise doubts to the competency of programmers
    • testers help identify all these areas and provide a better experience to users
  61. One Binary
    • having multiple binaries more prone to error
    • separate features core to application and platform
    • keep environment info versioned as well
  62. Only the Code Tells the Truth
    • refactor if you need comments
    • good structure, names and test to express intent
    • treat code like any other composition, that requires craft
  63. Own (and Refactor) the Build
    • code is useless without being deployed
    • build scripts are code / refactor
    • build is essential part of process and should be owned by dev team
  64. Pair Program and Feel the Flow
    • requires effort from individuals and team
    • promotes the distribution of skill and knowledge
    • reduces truck factor
    • solve problems effectively and have someone to discuss with and revisit solutions
    • integrate smoothly especially if the person wrote code
    • mitigate interruptions
    • bring people up to speed quickly
    • can be incredibly productive but also vulnerable
  65. Prefer Domain-Specific Types to Primitive Types
    • consider domain-specific types for higher quality software
    • in modern languages can use abstract data type class
  66. Prevent Errors
    • people make errors in predictable ways
    • try to limit the way input gets in e.g. calendar vs plain text
    • offer cues, people don’t read instructions
    • offer smart defaults
    • system should be tolerant
    • errors are results of misunderstandings between user and software
    • redesign to prevent future error
  67. The Professional Programmer
    • most important trait is personal responsibility
    • responsible for own career and learning / staying up to date
    • responsible for your estimates, commitments, and mistakes
    • for the code you write and make sure it works
    • team player, cover and help
    • do not tolerate big bug lists
    • do not make a mess, stay disciplined even under stress and pressure
  68. Put Everything Under Version Control
    • use version control, allows safe/bold changes
    • logical change in separate operations
    • explanatory message in each commit
    • don’t break build
  69. Put the Mouse Down and Step Away from the Keyboard
    • get away after you understand the problem and let idea marinade
    • your creative side may come up with a solution
  70. Read Code
    • read other people’s code
    • if hard, why hard? and avoid
    • if easy, why easy? adopt
    • review your own old code
    • if hard, are you still doing it that way?
  71. Read the Humanities
    • programmers like to ask for definitions built out of predicates which easily map to a class or table
    • generally not how people understand the world
    • they understand it off examples
    • if insist on Aristotelean answers, can’t ask users right questions
  72. Reinvent the Wheel Often
    • better way to learn than reading
    • intimate knowledge of inner workings
    • reinventing and getting it wrong is more valuable than getting right first time
    • like weight lifting to become a great programmer
  73. Resist the Temptation of the Singleton Pattern
    • often single instance requirement is imagined
    • implicit dependencies and coupling
    • implicit persistent state, hard to test and reason about
    • multithreading inefficient or not safe
    • restrict and don’t use singleton’s global access point from arbitrary code, instead direct access should only come from a few well-defined places
  74. The Road to Performance is Littered with Dirty Code Bombs
    • because of dependencies simple refactorings can balloon
    • damages credibility and political capital
    • consider using metrics e.g. fan-in/fan-out to get a sense of risk
  75. Simplicity Comes from Reduction
    • a lot of time spent wasted trying to salvage bad code
    • refactor mercilessly
    • start over in extreme cases
  76. The Single Responsibility Principle
    • subsystem, module, class or even function should not have more than 1 reason to change
    • reduces dependencies
    • in good system, components can be independently deployed
  77. Start from Yes
    • understand why and context
    • solve problem and satisfy request
    • question your own view
    • if compelling reason for incompatibility can have a productive conversation about it
  78. Step Back and Automate, Automate, Automate
    • not only for testing, more faster and reliable
    • gives you control and repeatability
    • don’t need exotic tools, decent shell language
    • start small and learn just enough
  79. Take Advantage of Code Analysis Tools
    • testing is only one tool of code quality
    • static analysis, configurable
    • can even roll own, many dynamic languages expose AST
    • useful to learn dusty corners and pick up gems
  80. Test for Required Behavior, Not Incidental Behavior
    • tests need to be sufficiently precise but also accurate
    • too specific can cause breaks due to minor implementation details
    • tests should state contractual obligations rather than parrot implementation
  81. Test Precisely and Concretely
    • appropriately constrain tets
    • good tests should be readable
  82. Test While You Sleep (and over Weekends)
    • can have mandatory tests for commit and more extensive tests that run overnight
    • support long-running tests
    • time on performance testing environment
    • test all permutations
  83. Testing Is the Engineering Rigor of Software Development
    • hard engineering have math and physics to use for structural solutions
    • software building is cheap
    • embrace testing as the primary (but not only) verification mechanism
    • “we don’t have time to test” like bridge builder saying “no time for structural analysis”
  84. Thinking in States
    • check you’re in the expected state before performing operations
    • protect your objects
    • understand state machines
    • test/unravel valid and invalid states
    • study state pattern and design by contract
  85. Two Heads Are Often Better Than One
    • programming is becoming more collaborative
    • interact not only with devs
    • pair programming great way to improve developers and get better quality work
    • the benefits are difficult to measure
    • pair with someone where you are weak
  86. Two Wrongs Can Make a Right (And Are Difficult to Fix)
    • single cause issues easier to fix
    • multiple causes needing multiple changes harder to resolve
    • awareness of the possibility, clear head, and willingness to consider all possibilities are needed
  87. Ubuntu Coding for Your Friends
    • code for others
    • think of other developers
    • zen vs ubuntu
  88. The Unix Tools Are Your Friends
    • unix commands are powerful, flexible, efficient, composable, and portable
    • easy to make your own / just follow a simple contract
    • IDEs usually language and task specific
  89. Use the Right Algorithm and Data Structure
    • important to understand algorithms and how they scale
    • use the right data structures
  90. Verbose Logging Will Disturb Your Sleep
    • log error if you’re willing to be woken up for it
    • one INFO level log per significant application event
    • distributed system / external dependencies / have a policy
  91. WET Dilutes Performance Bottlenecks
    • fewer places to fix or improve
    • raw collections break encapsulation, return domain-specific collection class
  92. When Programmers and Testers Collaborate
    • work together with testers
    • acceptance-test-driven development
    • test automation
    • help scope out requirements early
    • results in better quality
  93. Write Code As If You Had to Support It for the Rest of Your Life
    • gradually improve to become an expert programmer
    • leave a trail of knowledge, attitude, tenacity, professionalism, level of commitment
  94. Write Small Functions Using Examples
    • mathematically speaking, not just lines of code
    • by limiting possible inputs can prove the correctness
    • why using domain inspired types better than native type
  95. Write Tests for People
    • test the tests and make sure errors reported in a helpful way
    • have someone read it if they are confused, more likely something is not clear
  96. You Gotta Care About the Code
    • the real difference between adequate and great programmers is the attitude
    • want to write the best software you can
    • refuse to hack
    • code is discoverable and maintainable
    • leave better than you found it
    • write code that makes you proud
  97. Your Customers Do Not Mean What They Say
    • customers don’t always give you the full picture
    • interact with them more
    • restate problem using different words
    • talk to multiple people about the same topic
    • try using visual aids in conversations
Advertisement

Published by yujinjc

Leave a Reply

Fill in your details below or click an icon to log in:

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com account. ( Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. ( Log Out /  Change )

Cancel

Connecting to %s