DEV Community

Vitor
Vitor

Posted on

How to grow up and be noticed on your job

Ownership

  • Always leave the code better than you found it
  • If it's easy to change, change it on the spot
  • If it's not in production, there's no reason to be afraid of making mistakes
  • Open issue if your problem is not simple
  • If it's in production, open an issue to discuss with the team how to solve

Learn in Public

  • Always use public channels (social media or public channels on Slack)
  • Make articles about the problems that you have been solving and about what you learned on your day
  • Ask for feedbacks

Omnipresence

  • Review as many PR's as you can
  • Ask why to everything
  • Participate in all discussions
  • Discuss with others area, like marketing or something else

Top comments (15)

Collapse
 
aditmodi profile image
Adit Modi

Thank you for sharing, this is definitely helpful.

Give more value
Every employer wants their employees to contribute to the value of the company, so making a conscious effort to add value is one of the best ways grow on your job.

Collapse
 
ravavyr profile image
Ravavyr

Never be afraid to make changes, even in production. Just be quick to undo what you did, and as long as you understand what you did, prod won't be down for long enough for anyone to notice.
[disclaimer: Don't do this on very high traffic sites, duh]

Collapse
 
madza profile image
Madza

Some awesome tips here 👍✨

Collapse
 
abdosadory profile image
Abdelrhman Sayed El-Sadory

thanks for your post ❤❤
but what do u mean "If it's in production, open an issue to discuss later" ?
if the problem is in production period, should i insist to be solved in the same time or schedule it in future meeting ? 🙄🙄
thanks in advance 🌹🌹

Collapse
 
vit0rr profile image
Vitor • Edited

Thanks!
What I mean with this line is something like "open a issue to discuss some point later with the team", like a forum.

But I understand your point, and makes sense. I'll change this sentence.
I was based on an ideally scenery when nothing danger or critical is merged.

Collapse
 
criccode profile image
cricCode

Thank you for the article!
What should I be looking for while reviewing PR's? For most PR's the logic is something that takes quite some to understand and I don't think that should be the focus while reviewing PR's.

Collapse
 
vit0rr profile image
Vitor

You should review every PR's as you can because this will make you to understand more the codebase. Like what is merged, how some dev think to solve some problem, looking for patterns.

All this tricks will help to do smart copy and paste sibelius.substack.com/p/smart-copy....

And after some time you will understand a lot about the business logic and how your codebase works.

Collapse
 
vinibgoulart profile image
Vinicius Blazius Goulart

Great post!

Collapse
 
vit0rr profile image
Vitor

Thanks!

Collapse
 
gamerseo profile image
Gamerseo

The most important thing in work is commitment and acquiring knowledge on your own.

Collapse
 
saimwebhr profile image
Muhammad Saim Hashmi

These guidelines will surely help. Thanks for sharing.

Collapse
 
perssondennis profile image
Dennis Persson

These are actually great notes. It doesn't have to be technical to be a valuable post.

Collapse
 
italosantana profile image
Ítalo Santana

Great points! Thanks for sharing.

Collapse
 
dipbd1 profile image
Dip Chowdhury • Edited

Legend notes :D

Collapse
 
vit0rr profile image
Vitor

Thanks!