On top of some of the things that have already been mentioned by other folks, I would add this,
Don't take automation for granted. Always learn/know things running a layer deep.
I have encountered people who just push code to master and do not track/verify whether it actually got deployed to dev. If anything breaks in deployment, they literally don't know what to do next or how to fix it. This not only takes time of other person who now has to troubleshoot, that too only after someone realizes that the code is not getting deployed, but also when you are not tracking, it can create confusion for anyone who is testing that functionality.
Yup to most extend. As an example, if you have a Spinnaker pipeline which deploys the artifact, if everyone understood what different stages that pipeline has and what each phase does (what script/lib it uses), it would reduce time and effort in testing/troubleshooting/fixing. Not necessarily understand the script/lib itself code wise but atleast knowing/understanding what it does can help.
This thought can also be expanded to other areas as well. If you consume something internally, testing/troubleshooting becomes easy if we understand what that service/server, that we consume, is doing and what are some of its dev/deployement workflows.
On a different note, I especially agree with this one when it comes to learning frameworks but not having any clue about how the language actually works :).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
On top of some of the things that have already been mentioned by other folks, I would add this,
I have encountered people who just push code to master and do not track/verify whether it actually got deployed to dev. If anything breaks in deployment, they literally don't know what to do next or how to fix it. This not only takes time of other person who now has to troubleshoot, that too only after someone realizes that the code is not getting deployed, but also when you are not tracking, it can create confusion for anyone who is testing that functionality.
Do you mean, in this case, try to understand the tools you are using? Thx for the advice, much appreciated.
Yup to most extend. As an example, if you have a Spinnaker pipeline which deploys the artifact, if everyone understood what different stages that pipeline has and what each phase does (what script/lib it uses), it would reduce time and effort in testing/troubleshooting/fixing. Not necessarily understand the script/lib itself code wise but atleast knowing/understanding what it does can help.
This thought can also be expanded to other areas as well. If you consume something internally, testing/troubleshooting becomes easy if we understand what that service/server, that we consume, is doing and what are some of its dev/deployement workflows.
On a different note, I especially agree with this one when it comes to learning frameworks but not having any clue about how the language actually works :).