~ 3x/week - a letter (and podcast) for tech leads, engineering managers, and startup CTOs, giving you clarity, certainty, and confidence in the role. https://techleadcoaching.com
Refactoring is hard because there are several ways to solve problems...
One thing I think helps, tell me if you agree, is if you know a lot more about the mission of the project you're on. In some cases, the mission might be: "I just need to get some web ui out there RIGHT NOW to show some investors what our app might look like," in which case your first solution may be perfectly acceptable.
One the other hand, if you know you need a robust, flexible solution that's going to be around for a long time and be able to adapt to any solution, then what you refactored might be perfect.
So I think it's very important to work with your tech lead to make sure the vision for the task is super clear. If you're the tech lead, make sure you are clear about what the mission is. Then that context helps inform your low level design choices...
What do you think?
Pretty sure, by the way, that my early code was far worse than yours btw!! Fortunately, it's all long gone now!
I’m a web developer & data visualizer working at a think tank in D.C. I'm a self-taught dev trying to better my skills. I spend most of my time on the front end of the stack.
Location
Washington, D.C.
Work
Lead Developer at Center for Strategic and International Studies
Thanks so much! Glad you enjoyed it. :) And glad to hear I'm not the only one who has made some poor choices with their code before!
I absolutely agree that knowing more about the mission helps in determining in what works as a solution. There is a very real danger in over-engineering something that can be adequately done with less polish. However, I also think we need to be careful to not let poor code choices (like my original snippet) that are done for demo purposes make it into the final code base. I know I've written something quickly for sake of getting it done, didn't take the time to clean it up or think about a "proper" solution, and now it's sitting in production adding to that project's tech debt.
So yes, 99% agree with a 1% caveat to be mindful that poor code doesn't get moved to production because it's already "done". :)
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.
Awesome - thanks for posting Jacque!!
I think this point you make is key:
One thing I think helps, tell me if you agree, is if you know a lot more about the mission of the project you're on. In some cases, the mission might be: "I just need to get some web ui out there RIGHT NOW to show some investors what our app might look like," in which case your first solution may be perfectly acceptable.
One the other hand, if you know you need a robust, flexible solution that's going to be around for a long time and be able to adapt to any solution, then what you refactored might be perfect.
So I think it's very important to work with your tech lead to make sure the vision for the task is super clear. If you're the tech lead, make sure you are clear about what the mission is. Then that context helps inform your low level design choices...
What do you think?
Pretty sure, by the way, that my early code was far worse than yours btw!! Fortunately, it's all long gone now!
Thanks so much! Glad you enjoyed it. :) And glad to hear I'm not the only one who has made some poor choices with their code before!
I absolutely agree that knowing more about the mission helps in determining in what works as a solution. There is a very real danger in over-engineering something that can be adequately done with less polish. However, I also think we need to be careful to not let poor code choices (like my original snippet) that are done for demo purposes make it into the final code base. I know I've written something quickly for sake of getting it done, didn't take the time to clean it up or think about a "proper" solution, and now it's sitting in production adding to that project's tech debt.
So yes, 99% agree with a 1% caveat to be mindful that poor code doesn't get moved to production because it's already "done". :)