-
-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Tyranny of Nits blog post #239
Conversation
✅ Deploy Preview for leafwing-studios ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ideas here are solid, but the overall organization and flow needs some work. Some sections feel too long, and many of them don't feel well motivated or related to each other.
It kinda sounds like there are two parts to this post:
- Reviewers (at both the RFC and PR stage) adding tons of nits can seriously decay energy and morale
- Controversial changes can get deadlocked easily, and then die
These are both good things to talk about, but they feel kinda haphazardly smooshed together. I think they either need to be separated, or better integrated together.
The "controversial change lifecycle" section feels kinda disconnected from the rest of the post. It could maybe be separated into its own post, but it might make more sense to cut it entirely. I'm not sure how much it really adds, especially considering the other literature in this space. That could be fixed with better integration though.
Oh, another thing that might be good to add is a rule of thumb I use when reviewing: If I give a piece of feedback (especially something in the polish problems or compromise conflicts areas), I'll try to write it in such a way that clearly opens room for a counterargument. If the writer provides an argument for their decision that's even somewhat reasonable, I just drop it. Usually, as a reviewer, I'm mostly wanting to check that they actually thought about the problem, and to suggest a better way if they haven't. If they have, I'm usually happy to defer to their judgement, since they actually wrote it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow. Really significant improvements on round two. I really like this post, and I'm genuinely proud to have it on the leafwing site. I do have a few small suggestions (a typo or two, a missing connecting sentence or three, etc.), but I'm ok with publishing this as is if you want. I'll leave it to you how much of this round of feedback you want to incorporate before pressing the button. Nice work!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is one of the top articles for any software developer I have read. I mean every senior dev needs to read this!
Anyway sorry for nitpicking-ly try to polish this diamond like a Linter, I thought I'd read a bit but I was captivated and it was so great I couldn't stop reading..
Thanks a ton for the praise :D There's been a couple typo fix PRs merged; could you check against main? If you want to be particularly nice just make a PR of your own and I'll merge it asap! |
Checklist
Spot Checks
Editing passes
Social