4 ms·

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, oft

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. Thanks for your notes!

austincheney 5y ago
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.

austincheney 5y ago

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.