* Avoid OOP in JS (don’t use this). It buys you nothing, greatly expands the size of your code and vastly complicates maintenance.
* Be clear about requirements. If the requirements aren’t clear push back before doing any work.
* If you are working defects expect reproduction steps, a test location, defect state, and desired state. If this isn’t clear push back on it.
* if you cannot deliver code, because the work environment is shit, then deliver better documentation.
The problems I encounter at my work is that just about every is slow. Those who aren’t appear to hoard product knowledge and are really shitty at communicating. I really want to say that is intentional behavior but I just think it’s actually a mix of shitty code, fear of writing, and aggressive posturing by people who want attention compared to everyone else. The key failure here is that the employer rewards hard work without quality checks.
I agree, I went away from OOP in JS/TS years ago and don't see any need to use `this` these days with the functional approach.
Requirements, unfortunately, often are not clear from the very start, and more than that change, and actually their change is the part of agile processes, so I cannot dictate business to change this approach.
For tests and investigating bugs - totally agree, I always try to adopt the technique of providing the stakeholders with steps to reproduce a bug, including the very smallest factors - user/login, resetting data to the initial state before reproducing, checking the OS, date, language and so on.
In regards of the bad env, I try to improve it step by step. Even a small step is good, because it's always better to go through 15 steps rather than 16 to start app, to perform some user operation etc.
Requirements will change. This is a fact of life and must be solved with a combination of soft skills and business acumen. It must be known to the project/product leaders a change in requirements may impose rework and as such will invalidate any prior estimate. Furthermore it will require a new test plan. In a mature environment these things are clear before the changes arrive to you. In an immature environment these are risks and consequences that must be communicated back.
Sometimes poor development environments are a reflection of culture. If that is the case only a leadership solution will set things on a more productive direction. In cases where leadership is present and engaged a poor development environment is the result of missing technical guidance, which is likely due to a disconnect between a plan and actual implementation reinforced by developer driven decisions. Developers should never drive the direction of a product unless they are stakeholders with liability.
Just to be clear I am not a software leader. I am just an individual contributor, so take this with a grain of salt. I am a military officer though, in a secondary line of work, with director level responsibility and a large staff.
* Be clear about requirements. If the requirements aren’t clear push back before doing any work.
* If you are working defects expect reproduction steps, a test location, defect state, and desired state. If this isn’t clear push back on it.
* if you cannot deliver code, because the work environment is shit, then deliver better documentation.
The problems I encounter at my work is that just about every is slow. Those who aren’t appear to hoard product knowledge and are really shitty at communicating. I really want to say that is intentional behavior but I just think it’s actually a mix of shitty code, fear of writing, and aggressive posturing by people who want attention compared to everyone else. The key failure here is that the employer rewards hard work without quality checks.