How Do You Know? 📏
Apr 02, 2021 8:11 pm
Happy Friday!
This week I was inspired to write based on some other people's conversation. First up is about code reviews. While I do think code reviews are really valuable, I also believe there is an even better way to do them. So that's what one of my articles is about. What I didn't fit into the article though is that while I suggest pairing as a way to eliminate a review, a half-step is to do the review in-person or over a call instead of through a tool.
My other article is mostly about how a lot of groups and developers get fixated on what they consider a best technology or language. I've seen plenty of groups bet everything on a singular tech stack and find that after a few years they can't escape it anymore. Individuals form love affairs with their tools and spend many lunch-room conversations asserting it is the light and truth. I consider both of these extremes problematic as there are very rarely any clear-cut winners for any given situation.
If you have noticed you or your group are betting everything on the greatness of any one tool or technology, you might want to come up with a contingency plan. I can help.
I also have been thinking a lot about metrics and the strange relationship I see with them in organizations. On the one hand the crave metrics and transparency, and on the other they tend to writhe and wriggle out of them. Partly because metrics don't alway tell the story we want it to. Partly, it seems, because metrics are fairly uncommon to use in meaningful ways. Which leads me to this question–how do you know something is working or not?
I spend a lot of time with folks on this question, and it seems for most, they rely on the stories they hear and their experience of reading between the lines to stay aware of things. I should write about this more another time, but for now, this newsletter is too long!
Have a great weekend!
Here's my weekly update for April 2nd, 2021...
Code reviews are one of the most common practices in software development, but there is a better way.
I share the good and bad aspects of code reviews and a better way to do them.
Experienced folks, leaders, and new developers share something in common.
They fall in love with a specific technology.
This favoritism leads to some fairly pointless debate and, at its worst, some poor decisions.
Enjoy,
Ryan Latta