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.
Web Dev full-stack [LAMP] since 2005, but much heavier on the JS stuff these days.
Jack of all Stacks, Master of some.
Always looking to learn new things. Always glad to help out, just ask.
Location
Atlanta, GA
Education
B.S. in Biochemistry 2004, M.S. in Computer Information Systems 2007
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]
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 🌹🌹
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.
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.
Welcome to our profile. We are a video game marketing agency. We provide professional SEO and marketing services for the gaming industry. Please visit our website.
I'm a former teacher writing articles about software development and everything around it. My ambition is to provide people all around the world with free education and humorous reading.
Top comments (15)
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.
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]
Some awesome tips here 👍✨
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 🌹🌹
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.
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.
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.
Great post!
Thanks!
The most important thing in work is commitment and acquiring knowledge on your own.
These guidelines will surely help. Thanks for sharing.
These are actually great notes. It doesn't have to be technical to be a valuable post.
Great points! Thanks for sharing.
Legend notes :D
Thanks!