DO'S from "The Missing Readme"

Getting to Conscious Competence

DO play and experiment with code.

DO read design documents and other people's code.

DO join meetups, online communities, interest groups, and mentorship programs.

DO read papers and blogs.

DO prefer multicast and asynchronous communication.

DO shadow interviews and on-call rotations.


Working with Code

DO refactor incrementally.

DO keep refactoring commits separately from feature commits.

DO keep changes small.

DO leave code cleaner than you found it.

DO use boring technology.


Writing Operable Code

DO prefer compilation errors to runtime errors.

DO make things immutable whenever possible.

DO validate inputs and outputs.

DO study the WASP Top 10.

DO use bug-checking tools and types or type hinting.

DO clean up resources after exceptions (especially sockets, file pointers, and memory).

DO instrument your code with metrics.

DO make your application configurable.

DO validate and log all configuration.


Managing Dependencies

DO use semantic versioning.

DO pin dependency version ranges.

DO use dependency report tools for transitive dependencies.

DO be skeptical when adding new dependencies.

DO scope your dependencies.


Testing

DO use tests to reproduce bugs.?

DO use mocking tools to help write unit tests.

DO use code quality tools to verify coverage, formatting, and complexity.

DO seed random number generators in tests.

DO close network sockets and file handles in tests.

DO generate unique filepaths and database IDs in tests.

DO clean up leftover test state between test executions.


Code Reviews

DO make sure tests and linters pass before requesting a review.

DO set aside time for code reviews and prioritize them just like you do other work.

DO speak up if comments seem rude, unconstructive, or inappropriate.

DO help the reviewer by providing appropriate context for the change.

DO look beyond superficial style issues when doing a review.

DO use all your tools, not just the code review interface, to understand tricky changes.

DO review tests.


Delivering Software

DO use trunk-based development and continuous integration if possible.

DO use VCS tools to manage branches.?

DO work with release and operations teams to create the right processes for your application.

DO publish release changelogs and release notes.

DO notify users when a release is published.

DO use off-the-shelf tooling to automate deployment.

DO roll changes out gradually with feature flags.

DO use circuit breakers to prevent applications from causing major damage.

DO use traffic shadowing and dark launches for major changes.


Going On-Call

DO add known "pager" numbers to your phone's contacts.

DO use priority categories, SLIs,?SLOs, and SLAs to prioritize incident response.

DO triage, coordinate, mitigate, resolve, and follow up on critical incidents.

DO use the scientific method to troubleshoot.

DO ask "the five whys" when following up on an incident.

DO acknowledge support requests.

DO give time estimates and periodic updates.

DO confirm a problem is fixed before closing a support request ticket.

DO redirect support requests to the appropriate communication channels.


Technical Design Process

DO use a design document template.

DO read blogs, papers, and presentations to get ideas.

DO think critically about everything that you read.

DO experiment with code during design.

DO learn to write clearly, and practice often.

DO version control design documents

DO ask questions about teammate's designs.


Creating Evolvable Architecture

DO remember YAGNI: "You Ain't Gonna Need It."

DO use standard libraries and development patterns.

DO use an IDL to define your APls.?

DO version external APIs and documentation.

DO isolate application databases from each other.

DO define explicit schemas for all your data.

DO use migration tools to automate database schema management.

DO maintain schema compatibility if downstream consumers use your data.


Agile Planning

DO keep standup updates short.

DO write detailed acceptance criteria for stories.

DO only commit to work in a sprint that you can actually finish.

DO break up large chunks of work if you can't finish them in a sprint.

DO use story points to estimate work.

DO use relative sizing and T-shirt sizing to help with estimation.


Working with Managers

DO expect managers to be accessible and transparent.

DO tell your manager what you need DO set the agenda for your 1:1s.

DO keep 1:1 notes.?

DO write actionable feedback of the sort you'd like to receive.

DO track accomplishments to make self-reviews easier.

DO use the SBI framework to make feedback less personal.

DO think about long-term career goals.

要查看或添加评论,请登录

Dr. Tongjie "TJ" Zhang PhD, CISSP, ISSAP, CISM, GICSP, CEH, CTAJ, ICD.D的更多文章

社区洞察

其他会员也浏览了