I think this is a fairly good list for the 80% of pitfalls that will occur in a Software Developer's career. I think more can be said about the following topics however:
When and how to fight battles over code quality/ architectural design
This one has been very common in all the jobs I've had in my career. A simple mistake in these matters can and will lead to being ostracized by the team, and perhaps even termination from the company.
The main reason this is so hard is because egos are involved. I've joined up in companies where just about everything about the architecture of the systems is wrong. Everything about how the software is organized is wrong, and it's leading the company down a bad path of unpredictable, untestable systems living in production. Merely pointing this out to your new colleagues might be a bad move depending on the personalities of those who have perpetuated the bad system.
The worst case is when the most senior person on the team will not hear feedback, or want to improve the system. Worse yet is when they would like to improve the system, but the person with the purse strings is adamantly against ongoing software house-keeping.
I wish I had good answers for this problem, but I don't even know where to start. Sometimes it seems like resigning is the only correct solution.
Navigating which projects you get put on
This one is another difficult challenge that all of us will face at some point in our career. Being able to tell which project to avoid at all costs, and which will put us in a favorable light with the powers that be. Many projects have hidden pitfalls, and you might find yourself in too deep, trying and failing to fix an unfixable problem. Perhaps the project was barely functioning before you got put on it, and now that you're making any changes at all, it suddenly starts failing all the time. Whether you like it or not, people around the company think you are the reason for these failures.
The opposite can also happen, where you just luck into a project that everyone loves, and are regarded as a hero. Again, I wish I had more advice in this area, because it is quite difficult to navigate without lots and lots of experience.
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.
I think this is a fairly good list for the 80% of pitfalls that will occur in a Software Developer's career. I think more can be said about the following topics however:
When and how to fight battles over code quality/ architectural design
This one has been very common in all the jobs I've had in my career. A simple mistake in these matters can and will lead to being ostracized by the team, and perhaps even termination from the company.
The main reason this is so hard is because egos are involved. I've joined up in companies where just about everything about the architecture of the systems is wrong. Everything about how the software is organized is wrong, and it's leading the company down a bad path of unpredictable, untestable systems living in production. Merely pointing this out to your new colleagues might be a bad move depending on the personalities of those who have perpetuated the bad system.
The worst case is when the most senior person on the team will not hear feedback, or want to improve the system. Worse yet is when they would like to improve the system, but the person with the purse strings is adamantly against ongoing software house-keeping.
I wish I had good answers for this problem, but I don't even know where to start. Sometimes it seems like resigning is the only correct solution.
Navigating which projects you get put on
This one is another difficult challenge that all of us will face at some point in our career. Being able to tell which project to avoid at all costs, and which will put us in a favorable light with the powers that be. Many projects have hidden pitfalls, and you might find yourself in too deep, trying and failing to fix an unfixable problem. Perhaps the project was barely functioning before you got put on it, and now that you're making any changes at all, it suddenly starts failing all the time. Whether you like it or not, people around the company think you are the reason for these failures.
The opposite can also happen, where you just luck into a project that everyone loves, and are regarded as a hero. Again, I wish I had more advice in this area, because it is quite difficult to navigate without lots and lots of experience.