Tristan Walker

Eliminating distraction also extends to the "workplace" itself. Consider blocking off an hour or two a couple days a week for your focus period. To everyone else you'll appear to be in a meeting or otherwise unavailable. Without boxed off time for yourself to actually focus, being remote is a virtual open door for people to DM you, @ you, and otherwise flag your attention.

"Communication" doesn't just mean pointing out errors, ambiguity, etc. - it's a conversation. The reviewer isn't presumed to know everything and the author of the PR isn't presumed to be wrong until proven otherwise. Constructively pointing out missteps as well as asking for clarification can lead to surprising results. Sometimes you find someone trying to do something in a vacuum where the fuller effects of their changes weren't considered. Sometimes the reviewer may find themselves out of touch with current state of design. Without conversation these won't be known until possibly too late. And don't just leave these surfaced discoveries in old PR threads. If they're important details, they need to be documented for wider accessibility.

Don't waste time writing comments like "todo fix blah blah". Your org probably uses a ticketing system whose purpose is to capture that sort of thing. If you must comment that something in a file is incomplete, just comment the work ticket that will address it. Also in time as the codebase grows either directly in the same file that was commented or has a relationship to it, such comments may only serve to confuse others about the state of the code. Worse, the original author of such comments may completely forget to ever getting around to fixing whatever was noted. Also avoid very lengthy multiline comments outside of summaries for methods, etc.. This is what readmes are for and most SCMs and IDEs will natively render Markdown.

"Test your code" shouldn't just mean unit tests and automated suites. It should also be factoring in performance of the system itself through stress/load testing. Do you know where the breaking point is for your app? Does it buckle if it gets 100 requests in 1 second? Can you scale it? In what ways? Did scaling help ease performance issues? You cannot really answer any of those questions without building testing to functionally exercise the system and the metrics that clearly define healthy from unhealthy state. You really do not want to find out after shipping that your system has a bottleneck you cannot scale around or that a half-baked system is costing you a lot more to operate because it is simply inefficient.