- What attitude do you find bothering coming from a fellow dev?
- What could they do to improve?
Let's keep it simple and down to just 1 thing.
For further actions, you may consider blocking this person and/or reporting abuse
Read next
Part 3: C# Fundamentals: Operators and Expressions
Adrián Bailador -
Top 11 Web Hosting Powerhouses for 2025: Affordable, Lightning-Fast, and Ready to Perform!
Phaustin Karani -
Next.js Interview Mastery: Essential Questions 61-70 (Part 7)
Probir Sarkar -
A 50+ pages reactjs PDF cheat sheet with code examples of 30+ topics
Rowsan Ali -
Top comments (16)
The one thing that really puts me off is when my PR reviewer force-push commits on my PRs without any feedback. Peer reviews are not supposed to be one-way only: open the PR, let the tech lead finish it. The loop must be closed and you should get appropriate comments and feedback so that you can go back and fix the PR yourself.
As a PR reviewer, always make sure to communicate your thinking and your suggestions. Do not just push code to "fix" the things your way. It a disservice in the long term: they didn't learn because you didn't teach.
This sounds so weird to me because I've worked at 3 separate companies and I've never seen this happen! Didn't think anyone even did it.
Yeah it's the worst feeling ever :(
A dev that doesn't ask for help.
Take the time to research and figure things out on your own. Sometimes you don't know what you don't know. Maybe I explained something wrong. After a certain amount of time, like if your seemingly 30 min task takes 3 days, ask for help.
The following may happen:
I certainly wouldn't bite your head off or think you were dumb.
Do your research and come up with a plan. Limit the amount of time you should spin your wheels. Ask your colleagues or superiors for help when the task you've been given doesn't turn out the way you expected it to.
This!
Number 1 rule of every productive team: they ask for help.
Sure don't do it every 20 mins but don't let your ego make you spend 3 days on something that could've been solved in a 10 mins call.
I see this a lot. Definitely makes me question whether I might be the head biting type and not realize it.
Those that end up "gatekeeping" their knowledge with no documentation so you either go to them for help or start from the ground up. I've had a scenario where all the tools were built in a language I wasn't familiar with, and the guy ended up quitting without leaving any sort of information at all. While I was eventually able to fix things that started to break, a-lot of time could have been saved had there been meaningful READMEs, notes about their work, a git repository, SOMETHING.
I acknowledge this is more of a niche (at least I hope) experience, but it was really bothersome as a new developer.
Great advice! Always document your stuff. It'll be beneficial for someone else when you leave the company, or for your future self.
Not commenting their code/using vague variables (let item vs let productPriceItem). Yes, it may be your baby you know by heart, but I find that within a team, it's really selfish not to leave a few lines explaining what is pulled from where and what the method does. There are high chances someone else needs to drop in to maintain your code. Please be kind to their poor souls <3
Absolutely! they say "the best docs are no docs", that code should be so well written that it should be self-explained. I can't disagree with that more. A comment or a semantic variable will triumph over everything. It makes the codebase a lot more maintainable.
Thanks, Anzelika, keep it up! :D
Negativity. Don't shut down my idea and not offer your own in return.
Right. There are no bad ideas, just alternative solutions. But if you don't propose the alternative, my idea is still the best we have. :D
Well that just seems like a bad idea.
Those who don't bother to communicate or document their work.
I once had someone go into our codebase, change the setup and architecture of it, disable linting and remove existing documentation. The kind of huge PR with hundreds of files changed. PR title: "bugfix". Description: empty.
They didn't update the readme, didn't add any document their changes, didn't even tell anyone how to run the new code (because of course that had changed too). They approved their own PR and merged it in. Didn't tell anyone on Slack or Jira either. Was a great surprised that Monday morning.
At least it taught me what happens if you don't change your settings on GitHub and just trust people to ask for reviews 🤷♂️
Aghh that sounds terrible! Yeah, lesson learned, gatekeeping is necessary in most cases. Always put a description in your PR, ALWAYS!
Pre. Receive. Hooks.