Picture this: You've been grinding on a tricky problem for days. The bug was more elusive than you expected, the troubleshooting took way longer than you hoped, and you've been living in this code for what feels like forever. But you finally got it. You've tested it, cleaned it up, and you're satisfied with the solution. You submit your PR (pull request), feeling that small rush of accomplishment - you're done.
Then the code review comes back.
Some nitpicky comment about formatting. Or worse - a "suggestion" to fix something completely unrelated to your changes. Something that was already broken. Something that has nothing to do with the problem you just spent days solving.
And just like that, you're dragged back into that pain-in-the-ass ticket you thought you'd finished. That feeling of accomplishment? Gone. The momentum you had to tackle the next thing? Dead. Instead, you're annoyed, frustrated, and wondering why the hell this couldn't have been handled differently.
This is what happens when code reviews prioritize technical perfection over people.
Naming things is a core part of any programming. Almost everything needs a name and things being named well is an important factor in overall readability. Although coming up with good names may seem easy enough, there are some pitfalls that I see often. Here are ten things to avoid in your naming efforts.
I’ve seen an interesting phenomenon in witnessing different developer’s experience levels. Expertise and skills don’t always coincide with years of experience. Some developers with relatively short tenure have strong abilities, and some developers have stayed relatively stagnant for a long time. What makes the difference? While there may be differences in innate ability and aptitude, I believe there is also behaviors and mindsets that can push you towards becoming an expert developer faster.
