Hey all! š Iām Ryo, a Sr. Design Technologist at PlayStation. I do web dev with React/TS/Node and game dev with Unity/C#/C++/OpenGL/DirectX. Feel free to ask me any questions! š¤
"Hey team, we get to use the shiny new thing, and it'll make everything faster! Lets go go go"
// Never mentions the week-long integration struggle
Theres one mantra to follow.
If it ain't broke, don't fix it.
You have to think of a good enough reason to prove the product is "broken", and could be improved through refactoring.
The code style is so poor it costs more time editing - let's refactor and lint this
This old service is using outdated dependencies that are either dangerous or slower than modern solutions
This part of the website needs to be completely re-written in X because it'll help moving forward with Y
As a tech lead it can often be your job to weigh the need to refactor against these other factors (developer happiness, productivity, company budget, etc). You have to decide if you want to focus on cutting costs (like time spent coding) -- or you'd rather invest a loss of a profit for long term payoffs in the next quarter.
If you're not the tech lead, it helps to understand the complexity of that decision making process, and the scope at which you have to pose the problem to garner the right kind of attention.
Want to propose a refactoring from a non-leadership position?
1, Consider when you time it (is it during a sprint or downtime?)
Make sure to actually solve a problem (why get paid to move pixels needlessly?).
Be confident in your decision, and be able to possible prove it with small scale experiments. Seeing is believing.
I like your whole explanation here, but I specifically like that you mentioned experiments. You may even be able to do the experiment without mentioning it to anyone (depending). Once you have the results, you can present it - which may end up being an easier sell because you have the results. Like you said, seeing is believing.
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.
"Hey team, we get to use the shiny new thing, and it'll make everything faster! Lets go go go"
Theres one mantra to follow.
You have to think of a good enough reason to prove the product is "broken", and could be improved through refactoring.
As a tech lead it can often be your job to weigh the need to refactor against these other factors (developer happiness, productivity, company budget, etc). You have to decide if you want to focus on cutting costs (like time spent coding) -- or you'd rather invest a loss of a profit for long term payoffs in the next quarter.
If you're not the tech lead, it helps to understand the complexity of that decision making process, and the scope at which you have to pose the problem to garner the right kind of attention.
Want to propose a refactoring from a non-leadership position?
1, Consider when you time it (is it during a sprint or downtime?)
I like your whole explanation here, but I specifically like that you mentioned experiments. You may even be able to do the experiment without mentioning it to anyone (depending). Once you have the results, you can present it - which may end up being an easier sell because you have the results. Like you said, seeing is believing.