loading...

What bothers you about a dev?

caroso1222 profile image Carlos Roso ・1 min read
  1. What attitude do you find bothering coming from a fellow dev?
  2. What could they do to improve?

Let's keep it simple and down to just 1 thing.

Discussion

pic
Editor guide
Collapse
caroso1222 profile image
Carlos Roso Author

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.

Collapse
emma profile image
Emma Goto 🍙

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.

Collapse
caroso1222 profile image
Carlos Roso Author

Yeah it's the worst feeling ever :(

Collapse
inspiredbynikki profile image
Nikki

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'll realize I explained something poorly and correct myself
  • Give you more resources
  • Tell you there's a typo in your code
  • Show you a different path

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.

Collapse
caroso1222 profile image
Carlos Roso Author

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.

Collapse
v6 profile image
🦄N B🛡

I see this a lot. Definitely makes me question whether I might be the head biting type and not realize it.

Collapse
zferguson profile image
Zachary Ferguson

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.

Collapse
caroso1222 profile image
Carlos Roso Author

Great advice! Always document your stuff. It'll be beneficial for someone else when you leave the company, or for your future self.

Collapse
anzelika profile image
Anzelika

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

Collapse
caroso1222 profile image
Carlos Roso Author

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

Collapse
scrabill profile image
Shannon Crabill

Negativity. Don't shut down my idea and not offer your own in return.

Collapse
caroso1222 profile image
Carlos Roso Author

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

Collapse
v6 profile image
🦄N B🛡

There are no bad ideas, just alternative solutions.

Well that just seems like a bad idea.

Collapse
fossheim profile image
Sarah

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 🤷‍♂️

Collapse
caroso1222 profile image
Carlos Roso Author

Aghh that sounds terrible! Yeah, lesson learned, gatekeeping is necessary in most cases. Always put a description in your PR, ALWAYS!

Collapse
v6 profile image
🦄N B🛡

Pre. Receive. Hooks.