DON'TS from "The Missing Readme"

Getting to Conscious Competence

DON'T just churn out code.

DON'T be afraid to take risks and fail.

DON'T overdo conferences.

DON'T be afraid to ask questions.

Working with Code

DON'T overuse the phrase "technical debt."

DON'T make methods or variables public for testing purposes.

DON'T be a language snob.

DON'T ignore your company's standards and tools.

DON'T fork codebases without committing upstream.

Writing Operable Code

DON'T use exceptions for application logic.

DON'T use return codes for exception handling.

DON'T catch exceptions that you can't handle.

DON'T write multiline logs.

DON'T write secrets or sensitive data to logs.

DON'T manually edit configuration on a machine.

DON'T store passwords or secrets in configuration files.

DON'T write custom configuration formats.

DON'T use dynamic configuration if you can avoid it.

Managing Dependencies

DON'T use Git hashes as version numbers.

DON'T add dependencies unless the value exceeds the cost.

DON'T use transitive dependencies directly.

DON'T introduce circular dependencies.

Testing

DON'T ignore the cost of adding new testing tools

DON'T depend on others to write tests for you.

DON'T write tests just to boost code coverage

DON'T depend solely on code coverage as a measure of quality.

DON'T use avoidable sleeps and timeouts in tests.

DON'T call remote systems in unit tests.

DON'T depend on test execution order.

Code Reviews

DON'T make review requests just to get the Cl system to run.

DON'T rubber-stamp code reviews.

DON'T fall in love with your code or take feedback personally.

DON'T review code minutiae before understanding the big picture of the change.

DON'T nitpick excessively.

DON'T let perfect be the enemy of the good.

Delivering Software

DON'T publish unversioned packages.

DON'T package configuration, schema, images, and language packs together.

DON'T blindly rely on release managers and operations teams.

DON'T use VCSs to distribute software.?

DON'T change release packages once they're published.

DON'T roll out without monitoring the results.

DON'T depend on deployment ordering.

Going On-Call

DON'T ignore alerts.

DON'T try to troubleshoot during triage.

DON'T leave a problem unmitigated while you search for the root cause.?

DON'T cast blame during postmortems.

DON'T hesitate to close nonresponsive?support requests.

DON'T ask support requestors what their priority is; ask about the impact of the problem.

DON'T be a hero who has to fix all the things.

Technical Design Process

DON'T get attached to experimental code; it will change.

DON'T explore only one solution.

DON'T let a non-native language deter you from writing.

DON'T forget to update design documents if the implementation diverges from the plan.

DON'T be reluctant to participate in team design discussions.

Creating Evolvable Architecture

DON'T build too many abstractions without purpose.

DON'T write methods with hidden ordering or argument requirements.

DON'T surprise other developers with exotic code.

DON'T make incompatible API changes.

DON'T be dogmatic about internal API versioning.

DON'T embed schemaless data in string or byte fields.

Agile Planning

DON'T obsess over the "right way" to do Agile.

DON'T be afraid to change Agile processes.

DON'T force regular task descriptions into "stories.

DON'T forget to track planning and design work.

DON'T add work after sprints begin if committed work is not yet done.

DON'T follow processes blindly.

Working with Managers

DON'T hide difficulties from your manager.

DON'T use 1:1s as a status update meeting.

DON'T work from memory when writing self-reviews.

DON'T write superficial feedback.

DON'T get boxed in by OKRs.

DON'T take feedback as an attack.

DON'T put up with bad management.