This was originally published in my free weekly newsletter, Dev Finds Friday. It's like having that cool friend who sends you all the best links on the internet (but better).
Onto the the links!
I've been thinking a lot lately about how to conduct human code reviews. I use the word human there on purpose because I've found that some devs take a perverse pleasure in ripping apart code without giving a second thought to how the information is communicated.
Our industry has a reputation for not being human, in other words, and our code reviews are often inhumane.
Some of us like that.
Many of us don't.
None of us should.
So, let's inject a little humanity into our code review process.
Here's a few thoughts on how:
Make it clear what feedback is blocking and non-blocking. Don't hold work up because you have some minor nitpicks. Netlify put out a great piece on their Feedback Ladder that applies here.
- DON'T assume the person whose code you're reviewing thinks the same way as you, or that the way you're thinking about the problem is the one true solution.
- DON'T assume they know what you know. Provide links to blog posts, Stack Overflow answers, GitHub issues, and whatever else.
- DO assume they've already considered your suggestion before. Ask them how they arrived at their solution, and if they thought about your suggestion.
Encourage what's good. Code reviews shouldn't be all negative.
Consider how you're coming across. What's your tone? Is it dismissive?
If matters of style and formatting come up a lot, adopt team wide linting rules/a code formatter.
I'm planning on writing more on this in the future. It's an important topic we could all improve (myself included) because, after all, we're only human.
Onto the links!
Write Libraries, Not Frameworks: "Frameworks aren't always bad, but they are a much bigger risk - for both the creators and the users - than libraries are. If your framework can be a library without losing much, it probably should be. If you don't work at a major tech company, you probably don't have the time or energy to give a framework all of the attention it requires. Libraries aren't everything, but they should be preferred."
Moss Garden: A stream of ambient music perfect to listen to while programming.
**Why does writing matter in remote work?: **Many, many reasons.
It saves time.
It makes meetings a last resort.
It removes extrovert bias.
It invites other perspectives.
Blush, Illustrations for everyone: A neat little (FREE) collection of those doodles of people that every startup uses on their landing pages. You’ll see what I mean.
My Mid-Career Job-Hunt: I've only had 2 job hunts for dev roles, so, I seeing what the process is like for others. What helped the author land a gig:
Speaking at conferences.
Having a blog (though not as much as the author would have thought).
Having a special branded resume for each company (you'll have to read the article to see what I mean).
Being Slow to Criticise: "I try to be slow to jump to that conclusion, that the software is garbage. So often there are reasons for things to be the way they are."
Rebuilding our tech stack for a new Facebook.com: A more clickbaity title would be "You'll never believe how Facebook reduced their CSS by 80%."
Some curmudgeons are fond to remind others that they're not Google or Facebook, but on the front end we deal with a lot of the same problems and bottlenecks. Helpful to see how one top tier engineering team is pushing their app forward.
What accomplishments sound like on software engineering resumes: Nicely complements last week's link from Sarah Drasner, Advice for Writing a Technical Resume.
A couple more links I came across in this vein:
Lots of examples on how to be specific with your professional accomplishments.
The joy of sets - BBC Archive: Spice up your Zoom calls with backgrounds from famous BBC show sets.
That's all I've got.
If you're a curious dev, and that sounds like something you'd like to get directly to your inbox, sign up: Dev Finds Friday.
Stay healthy and thanks for reading!