code-review

Pull requests are a chance to ask, learn, and make sure that the code being merged is something EVERYONE is comfortable owning.

I was creating a document in Office365 the other day - something I’ve done a hundred times - but when I tried to paste with their custom right-click menu I was greeted with a popup telling me to download a browser addon. Well, that’s weird.

If you’ve ever dug into the underpinnings of a browser extension, or maybe even created one yourself, you’ve seen the manifest.json file that acts as a sort of usage guide for an extension. Not the kind of usage guide most people would want to read, but it’s vital for browsers. The manifest file tells them what name and version to display, who the author is, what permissions to request access to, which icons to display, what css and js files to load and when. It’s important, but once you get the hang of it, pretty simple to implement. You create it and move on, only ever reopening it to bump the version when you’ve got something new to publish, and maybe requesting a new permission. ...

Does the mere thought of explaining your code cause anxiety? Be confident! We should all understand what we’re writing and why. It’s an opportunity (for everyone) to learn!

Does the idea of submitting to a code review make you sweat bullets? Or do you brush it off as a necessary evil? It should be a (hopefully positive) conversation, wherein the team agrees to the code they’re all going to have to help maintain, and maybe learns something new too.

I was checking the status of a FedEx order when Brave warned me that “this site has been blocked from accessing your motion sensors”. I’m struggling to understand why a website would need that access. Do I get a different experience if I drop my device? Tip my monitor over? Spin the mouse around?