Interesting read. Chasing perfection can be a real trap, as we are essentially trained to find flaws and improve things. That can easily turn into a never-ending cycle of fiddling with code without any clear end goal or time frame. One thing I struggle with is not overworking an issue. Setting hard deadlines can help as a form of backpressure, but sometimes it's really hard to let problems go.
I also think some languages are especially prone to this kind of issue, particularly the ones focused on functional programming. I remember working with Scala and being amazed and alarmed by how many different ways you could write the same statement with increasing levels of abstraction. It wasn't uncommon for a team member to refactor a part of the codebase with a new DSL simply because it wasn't purely functional enough.
I guess people have different ideals of perfection, which can create that sort of disconnect when somebody wants to change/refactor something simply because it doesn't match their ideal.
It's definitely a balance between making sure you're constantly finding problems and improving things like you said; considering that's the engineer's job and what we get paid to do but also knowing when is right to let things go. Doing the latter is the hard part.
2 comments
[ 2.5 ms ] story [ 14.8 ms ] threadI also think some languages are especially prone to this kind of issue, particularly the ones focused on functional programming. I remember working with Scala and being amazed and alarmed by how many different ways you could write the same statement with increasing levels of abstraction. It wasn't uncommon for a team member to refactor a part of the codebase with a new DSL simply because it wasn't purely functional enough.
It's definitely a balance between making sure you're constantly finding problems and improving things like you said; considering that's the engineer's job and what we get paid to do but also knowing when is right to let things go. Doing the latter is the hard part.